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.
[ad]
