So it was time to move a LAN which was protected by a simple Cisco extended access-list behind the checkpoint firewall (cluster) of a customer.
The migration went very smooth, we created all the hosts & policies on the firewall prior to changing the IP addresses & VLANs as the MOP we had created suggested and the network was switched to the DMZ with minimum retransmissions during the transition.
The rules worked fine and everything went well, we monitored the network traffic for around 1 hour as it was planned and closed the activity as successful.
Everything on the firewall logs seemed proper, most of the servers behind this network are SIP servers / proxies for IP telephony.
UDP and TCP packets were flowing seamlessly, we even noticed that the IPS of the Checkpoint was rejecting multiple re-invites on SIP protocol (even before the local fail2ban on the SIP servers was taking actions).
Next morning, our customer had several (random) calls for problems with initiating calls (incoming calls). We started investigating the issue only to find after taking traces that some specific type of CPE’s replies to our SIP proxy invite requests were transformed to ICMP packets which included the replies on the invite requests. This lead to rejection of the packets from the SIP proxy and failure of call setup.
The quick resolution in order to investigate further the problem (and understand it’s nature) was to switch the IPS from Prevent to Detect mode. As soon as this was configured and policy was installed, this strange behaviour stopped occurring and call setups were successful.
The proper workaround is to create a custom UDP port for port 5060 (or any other port your SIP is configured to initiate sessions) and make sure that its type is set to none as this will prevent the packets from being inspected by the IPS.
After resolving this issue, the first thing that came to my mind was: “I will tell you a UDP joke but I am not sure you’ll get it!”
