Checkpoint Firewall-1 and The SIP Protocol

You have an asterisk based VoIP phone system sitting on an internal network and you are trying to establish connectivity to a SIP-based trunk provider.

You configure a static NAT entry 1-to-1 for the asterisk box and allow the SIP (udp 5060) through the firewall, but SIP registration fails constantly.

While troubleshooting the issue you observe some strange behavior in the NAT. The SIP registration packet (source port 5060, destination port 5060) reaches the firewall, changes the source port at the interior interface and to another high port at the exterior interface, but the answer packet will not be translated correctly.

Fw monitor shows the following:

a.b.c.d is the internal (private) IP address
n.n.n.n is the external (public) IP address
w.x.y.z is the SIP providers IP address

eth1.10:i[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 5060 -> 5060

eth1.10:I[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 17973 -> 5060

eth0:o[502]: a.b.c.d -> w.x.y.z (UDP) len=502 id=0

UDP: 17973 -> 5060

eth0:O[510]: n.n.n.n -> w.x.y.z (UDP) len=510 id=0

UDP: 40625 -> 5060

eth0:i[404]: w.x.y.z -> n.n.n.n (UDP) len=404 id=5495

UDP: 5060 -> 40625

eth0:I[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

eth1.10:o[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

eth1.10:O[398]: w.x.y.z -> a.b.c.d (UDP) len=398 id=5495

UDP: 5060 -> 17973

As it can be seen the reply does not get translated back as it should to destination port 5060 and thus will not be accepted by the asterisk box.

To understand and be able to solve the current dilemma its imperative that we explore why the Checkpoint Firewall is behaving this way and preventing our Asterisk box from registering the SIP trunk.

The Stateful Inspection Technology implements all the necessary firewall capabilities at the network level. The FireWall-1 Inspection Module accesses and analyzes data derived from all communication layers. The FireWall-1 Security Server enables the system administrator to define a Security Policy on a per-user basis.

The Inspection Module is located between the Data Link (IP-Stack) and Network Layer (Device Driver). Authentication and Content Security are provided by a suite of FireWall-1 Security Servers, running at the application layers.

The Security Servers enforce Content Security and Authentication for a particular service. Defining a protocol type within an associated service invokes specific protocol handlers enabling a higher level of security by parsing the protocol, and a higher level of connectivity by tracking dynamic actions and these checks are mostly overridden by SmartDefense checks.

So to recap. As the data moves up the OSI layers, it can be intercepted by both the Security Servers and SmartDefense. In this particular case the protocol definition which invokes specific protocol handlers are modifying the reply SIP packets during translation using a random port and not the UDP 5060 asterisk is expecting.

Modifying the Protocol Type on the udp-sip service under the “Advance UDP Services Properties” from SIP_UDP to None will solve the issue.


  • I am having the same problem with outbound SIP connections getting their source port mangled by Check Point. I have modified my SIP service to the 'none' protocol handler, but the source port mangling is still taking place. How did you get Check Point to leave the source port alone on outbound SIP connections?

    Any help would be appreciated.

  • Have you tried playing around with the smartdefense settings.? Under SIP the only option disabled should be to block calls from unregistered users as this will be done by the asterisk box. Under SIP custom properties, the only option checked should be to block SIP calls that use two different voice connections and under SIP filtering you should not do any filtering and not drop unknown SIP methods. You should a rule on your firewall allowing udp 5060 and udp >10000 & < 20000. On your asterisk box, your sip_custom.conf config file should look like this.

    bindport = 5060


    externip=[public ip address]


    Hope this helps.

  • I disabled SmartDefense to make sure it wasn't the problem. As for the externip settings, I have those NAT settings in place buy my provider is still sending me traffic to my internal IP rather than to my external IP. I'm not sure how it's even making it back to me, but it seems like it should be coming to the host defined in externhost or externip.


  • Have you solved this yet? Have you tried increasing the UDP virtual session timeouts? Any performance issues on the firewall? Have you tried moving the sip rule closer to the top of the rule base? and do you have cleanup rules at the bottom for high port udp traffic?

  • I solved it by moving to a Linksys router. A $40 system handles the NAT better than Check Point. Quite sad.

    • Duderonomy

      were you using manual or automatic NAT?
      Auto-NAT seems to work fine, but anything else causes it to crap out.
      We're still having the same problem, after removing manual NAT rules, upgrading to R65 HFA 02, changing protocol type to none, disabling MGCP and SIP SmartDefense protections. On the phone with CP support for over four hours the other night with no success. Does anyone have any other suggestions?

  • Pingback: SIP-ing Through the Firewall | D/Line Radio()