Problems with Check Point, NAT, and SIP

By Daniel Miessler on February 18th, 2009: Tagged as Technology | VOIP

57iCT

Scenario

  1. You have an Asterisk server behind a Check Point firewall trying to contact a VOIP provider located on the Internet

Problem

  1. SIP requires that your VOIP provider be able to contact you through your firewall on the port that you registered from
  2. When your Asterisk box registers it registers with both source and destination port of UDP 5060
  3. Unfortunately, Check Point NATs the source port on the way out to some random high-numbered port
  4. The VOIP provider sees that high-numbered port as the return port number, and initiates contact with you on that port
  5. Check Point takes that incoming high-numbered port traffic and sends it back to the Asterisk server-WHICH THE ASTERISK SERVER ISN’T LISTENING ON
  6. The Asterisk server responds with ICMP Port Unreachable messages, basically saying, “Dude, I said 5060–what the hell is this other crap you’re sending me?”

Rant

Basically, the issue is that you can’t tell Check Point to NOT mangle the source port of your outgoing SIP connections.

I’ve tried static NAT and I’ve tried editing the SIP service so that it uses the “none” protocol handler. Nope. Regardless of the settings used, Check Point changes the source port on the way out and breaks SIP.

The really sad part is that Linksys has solved this problem; you can configure a cheapo router to use the original source port–but not a full, enterprise-level Check Point box. It makes me physically ill. ::

[ I'm using a fully functioning demo of R65, for those of you who asked. The fact that it's a trial doesn't effect its NAT functionality ]

  • http://dmiessler.com/ Daniel Miessler

    Hopefully I missed something. If anyone knows a solution for this I'd love to hear about it.

  • RafalWeglarz
  • http://dmiessler.com/ Daniel Miessler

    Nope, that's the protocol handler trick I mentioned I already tried. Didn't work. But thanks for the link; I appreciate the effort.

  • ghost16825

    Er….are you serious?
    So you mean you can't create an inbound port forwarding rule? (which on most devices implies that the outbound source ports will be preserved)
    Also are you sure the device doesn't have any SIP Application Layer Gateway functionality enabled?

  • RafalWeglarz

    Hi,
    I have tested it. And although CheckPoint does change the source port, it does properly handle messages coming back. It properly changes the ports.
    You mentioned that it is during the initial phase. If it not be during initial phase than I would guest that the problem might be that the UDP session times out. But it should be alive for at least 40 seconds (which is default). Could you provide me with pcap dumps? I do not want to install the whole asterisk thing :)

  • http://www.securitybalance.com Augusto Paes de Barros

    It should be handled by the “UDP virtual session” concept. The problem would be if the interval between UDP packets is too big, as the firewall will clean the state tables and will not understand the incoming packet as part of a previous “virtual session”. If the communication is something regular it can be solved by increasing the UDP virtual session timeout, but if the packet flow is not constant (i.e. there are long time intervals between each UDP packet) it won't help at all.

    For some stuff like this one, Check Point should have more granular controls, like UDP virtual session timeouts per protocol and/or rule.

  • RafalWeglarz

    I think I get the problem now ;). I'm not the VOIP guy, but isn't there any setting in Asterisk that says how external servers should reach it? So that you could do a mapping of extip:port->intip:port?
    Besides it seems that VOIP is broken in the first place ;)

  • http://dmiessler.com/ Daniel Miessler

    The problem isn't the incoming port mapping; it's the outgoing SIP connection coming from the Asterisk system. The Check Point system doesn't give the packets back to port 5060 on the Asterisk box (the original source port); instead it gives it to the Asterisk box as the high level port IT created, which of course isn't accepting traffic–hence the ICMP unreachables.

  • http://dmiessler.com/ Daniel Miessler

    Ok, I tried this and it looks like it's solved most of my problem. Awesome.

    I did, however, get a failed call after placing an outgoing call, and received a bunch of unreachables like before. I wonder if it's because during the call I didn't have any outgoing registrations occurring (I haven't tested that yet), which would possibly cause the existing session to time out. If that's the case then it's going to be highly annoying to have to accept that I'll miss some calls if they happen to fall within a certain window.

    Any thoughts on how to handle that? Should I increase my virtual session window even more to try and account for that? I want to avoid getting too extreme with it, and would rather implement a real solution than some sort of hack to get around this.

    Thanks very much for the virtual session timeout tip, though–that seems to have have solved most of my unreachable issue.

  • Pingback: Check Point and Streaming Video

  • http://www.vinoblog.de TabTwo

    The basic issue here: SIP just sucks with NAT

    Why should a NAT-device user the same source port? What if a second connection uses the same?

  • http://www.vinoblog.de TabTwo

    The basic issue here: SIP just sucks with NAT

    Why should a NAT-device user the same source port? What if a second connection uses the same?

  • Matt Peterschlingmann

    Actually … you can get it to work.

    I hit this issue yesterday and found your post, as I was having the same trouble as you.

    Solution:

    Create a VOIP Domain object that contains “related enpoints” of your internal LAN whereby your Asterisk server resides. “VoIP Gateway installed at ” is defined as your external IP.

    define 2 rules:

    1) SRC LAN DEST ANY PORT SIP

    2) SRC ANY DEST VoIP DOMAIN PORT SIP_ANY

    and create corresponding nats.

    my sip.conf also contains the line:

    externip : xxx.xxx.xxx.xxx

    Where (x) is your IP.

  • Matt Peterschlingmann

    Actually … you can get it to work.

    I hit this issue yesterday and found your post, as I was having the same trouble as you.

    Solution:

    Create a VOIP Domain object that contains “related enpoints” of your internal LAN whereby your Asterisk server resides. “VoIP Gateway installed at ” is defined as your external IP.

    define 2 rules:

    1) SRC LAN DEST ANY PORT SIP

    2) SRC ANY DEST VoIP DOMAIN PORT SIP_ANY

    and create corresponding nats.

    my sip.conf also contains the line:

    externip : xxx.xxx.xxx.xxx

    Where (x) is your IP.

  • Search4it

    Please clarify exactly what you put into the “corresponding nats”. I am having similar issue but cant resolve it. Thanks

  • http://voipsoftwares.org VoIP software

    I do not have firewalls in my cell phone, so is that OK?


Top

Popular

Information Security / Technology

Politics

Philosophy & Religion

Technology & Science

Culture & Society

Miscellaneous

Arguments

Projects

Collections

Twitter

What I'm Reading

Favorite Books and Essays

Top Blog Categories

Inputs