[Serusers] Illegal redirection
sip
sip at arcdiv.com
Tue Nov 15 15:12:57 CET 2005
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 at lists.iptel.org
> >>http://lists.iptel.org/mailman/listinfo/serusers
> >>
> >>
> >
> >
> >
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
More information about the sr-users
mailing list