Hello I have two Cisco 7940 phones with private addresses (10.0.11.239 and 10.0.11.140) connected to SER also with private address (10.0.0.135), but in another network.
My SER is with the default configuration.
Between the networks I have a Checkpoint Firewall-1NG The Cisco IP phones can register because the REGISTER packets arent blocked. But the INVITEs never reach SER (I checked with ngrep), because the Firewall drops them, saying there was an illegal redirection.
The most strange part, is that, when I try to make a phone call from PhoneA(10.0.11.239) to PhoneB(10.0.11.240), the INVITE is dropped before reaching SER, and it says "Illegal redirection 10.0.0.135->10.0.11.240". How can the firewall know that the INVITE was going to be redirected by SER to PhoneB(10.0.11.240) ????
my ser.cfg (the default one):
# $Id: ser.cfg,v 1.25 2004/11/30 16:28:24 andrei Exp $ # simple quick-start config script
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E)
listen = 10.0.0.135
/* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R)
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/textops.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route();
# subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; };
if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; };
# if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) {
if (method=="REGISTER") {
save("location"); break; };
lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; };
# native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1); }
route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
Checkpoint firewalls contain stateful SIP packet inspection. It will look into the packet and decide whether it should be dropped or allowed based on the contents of the SIP message.
I guess you would have to change some settings in the firewall to make the messages go through.
I would recommend you to use something else than Checkpoint firewalls. We have had troubles with this vendor.
Jan.
On 15-11-2005 12:38, Joao Pereira wrote:
Hello I have two Cisco 7940 phones with private addresses (10.0.11.239 and 10.0.11.140) connected to SER also with private address (10.0.0.135), but in another network.
My SER is with the default configuration.
Between the networks I have a Checkpoint Firewall-1NG The Cisco IP phones can register because the REGISTER packets arent blocked. But the INVITEs never reach SER (I checked with ngrep), because the Firewall drops them, saying there was an illegal redirection.
The most strange part, is that, when I try to make a phone call from PhoneA(10.0.11.239) to PhoneB(10.0.11.240), the INVITE is dropped before reaching SER, and it says "Illegal redirection 10.0.0.135->10.0.11.240". How can the firewall know that the INVITE was going to be redirected by SER to PhoneB(10.0.11.240) ????
my ser.cfg (the default one):
# $Id: ser.cfg,v 1.25 2004/11/30 16:28:24 andrei Exp $ # simple quick-start config script
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E)
listen = 10.0.0.135
/* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R)
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/textops.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { save("location"); break; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1);
}
route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
The firewall says that our SIP implementation doesnt follow one of the RFCs or the packets are malformed. To test this, I started SER with the default configuration, that simply accepts registrations and redirects the INVITEs and It still doesnt work. The Firewall vendors said that it supported SIP... That´s why I need to know if the problem is from SER or Cisco phones or with the firewall.... I cant change the firewall :( What do you mean with having troubles with the vendor? Are you talking of the hard SIP configuration of the firewall 1? Thanks João Pereira
Jan Janak wrote:
Checkpoint firewalls contain stateful SIP packet inspection. It will look into the packet and decide whether it should be dropped or allowed based on the contents of the SIP message.
I guess you would have to change some settings in the firewall to make the messages go through.
I would recommend you to use something else than Checkpoint firewalls. We have had troubles with this vendor.
Jan.
On 15-11-2005 12:38, Joao Pereira wrote:
Hello I have two Cisco 7940 phones with private addresses (10.0.11.239 and 10.0.11.140) connected to SER also with private address (10.0.0.135), but in another network.
My SER is with the default configuration.
Between the networks I have a Checkpoint Firewall-1NG The Cisco IP phones can register because the REGISTER packets arent blocked. But the INVITEs never reach SER (I checked with ngrep), because the Firewall drops them, saying there was an illegal redirection.
The most strange part, is that, when I try to make a phone call from PhoneA(10.0.11.239) to PhoneB(10.0.11.240), the INVITE is dropped before reaching SER, and it says "Illegal redirection 10.0.0.135->10.0.11.240". How can the firewall know that the INVITE was going to be redirected by SER to PhoneB(10.0.11.240) ????
my ser.cfg (the default one):
# $Id: ser.cfg,v 1.25 2004/11/30 16:28:24 andrei Exp $ # simple quick-start config script
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E)
listen = 10.0.0.135
/* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R)
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/textops.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { save("location"); break; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1);
}
route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
There have been numerous problems with the SIP inspection of the Checkpoint firewalls. It's a double-edged sword, unfortunately. Some people have fixed the issue by removing all references to SIP and just creating a generic UDP service at port 5060, but this takes away all the functionality of the firewall being SIP-aware.
N.
On Tue, 15 Nov 2005 13:47:19 +0000, Joao Pereira wrote
The firewall says that our SIP implementation doesnt follow one of the RFCs or the packets are malformed. To test this, I started SER with the default configuration, that simply accepts registrations and redirects the INVITEs and It still doesnt work. The Firewall vendors said that it supported SIP... That´s why I need to know if the problem is from SER or Cisco phones or with the firewall.... I cant change the firewall :( What do you mean with having troubles with the vendor? Are you talking of the hard SIP configuration of the firewall 1? Thanks João Pereira
Jan Janak wrote:
Checkpoint firewalls contain stateful SIP packet inspection. It will look into the packet and decide whether it should be dropped or allowed based on the contents of the SIP message.
I guess you would have to change some settings in the firewall to make the messages go through.
I would recommend you to use something else than Checkpoint firewalls. We have had troubles with this vendor.
Jan.
On 15-11-2005 12:38, Joao Pereira wrote:
Hello I have two Cisco 7940 phones with private addresses (10.0.11.239 and 10.0.11.140) connected to SER also with private address (10.0.0.135), but in another network.
My SER is with the default configuration.
Between the networks I have a Checkpoint Firewall-1NG The Cisco IP phones can register because the REGISTER packets arent blocked. But the INVITEs never reach SER (I checked with ngrep), because the Firewall drops them, saying there was an illegal redirection.
The most strange part, is that, when I try to make a phone call from PhoneA(10.0.11.239) to PhoneB(10.0.11.240), the INVITE is dropped before reaching SER, and it says "Illegal redirection 10.0.0.135->10.0.11.240". How can the firewall know that the INVITE was going to be redirected by SER to PhoneB(10.0.11.240) ????
my ser.cfg (the default one):
# $Id: ser.cfg,v 1.25 2004/11/30 16:28:24 andrei Exp $ # simple quick-start config script
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E)
listen = 10.0.0.135
/* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R)
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/textops.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { save("location"); break; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1);
}
route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I was talking about the SIP ALG in the firewall. It did not allow SIP traffic that was standard compliant through. A checkpoint engineer said that according to *him* it was not standard use of SIP. The best you can do is junk Checkpoint and use something else.
Jan.
On 15-11-2005 13:47, Joao Pereira wrote:
The firewall says that our SIP implementation doesnt follow one of the RFCs or the packets are malformed. To test this, I started SER with the default configuration, that simply accepts registrations and redirects the INVITEs and It still doesnt work. The Firewall vendors said that it supported SIP... That´s why I need to know if the problem is from SER or Cisco phones or with the firewall.... I cant change the firewall :( What do you mean with having troubles with the vendor? Are you talking of the hard SIP configuration of the firewall 1? Thanks Jo??o Pereira
Jan Janak wrote:
Checkpoint firewalls contain stateful SIP packet inspection. It will look into the packet and decide whether it should be dropped or allowed based on the contents of the SIP message.
I guess you would have to change some settings in the firewall to make the messages go through.
I would recommend you to use something else than Checkpoint firewalls. We have had troubles with this vendor.
Jan.
On 15-11-2005 12:38, Joao Pereira wrote:
Hello I have two Cisco 7940 phones with private addresses (10.0.11.239 and 10.0.11.140) connected to SER also with private address (10.0.0.135), but in another network.
My SER is with the default configuration.
Between the networks I have a Checkpoint Firewall-1NG The Cisco IP phones can register because the REGISTER packets arent blocked. But the INVITEs never reach SER (I checked with ngrep), because the Firewall drops them, saying there was an illegal redirection.
The most strange part, is that, when I try to make a phone call from PhoneA(10.0.11.239) to PhoneB(10.0.11.240), the INVITE is dropped before reaching SER, and it says "Illegal redirection 10.0.0.135->10.0.11.240". How can the firewall know that the INVITE was going to be redirected by SER to PhoneB(10.0.11.240) ????
my ser.cfg (the default one):
# $Id: ser.cfg,v 1.25 2004/11/30 16:28:24 andrei Exp $ # simple quick-start config script
# ----------- global configuration parameters ------------------------
debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=yes # (cmd line: -E)
listen = 10.0.0.135
/* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */
check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R)
# ------------------ module loading ----------------------------------
loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/textops.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("usrloc", "db_mode", 0)
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; };
# we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { save("location"); break; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1);
}
route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers