Hi Mates!
I'm wondering if anyone has similar issues with Hide NAT in R82.
We just updated our Check Point perimeter firewall from R81.20 to R82 and while everything seems to work fine, we have some new issues with VoIP. I know VoIP can be a pain, but this specific problem is new to me.
We have a Session Border Controller which connects to the Microsoft Teams Cloud so people can call with MS Teams to traditional phone lines and vice versa. The SBC has a private IP in a DMZ behind our Check Point perimeter firewall, so we apply NAT:
- 2 inbound statics from the internet to the public IP we assigned to the SBC.
- One for sip_tls_not_inspected (tcp/5061)
- And one for the UDP port range the SBC is configured for, in this case 8000-8999, for the audio streams of the call.
- 1 outbound Hide NAT to hide the outbound traffic from the SBC behind the public IP we assigned to the SBC.
Provider VoIP Trunk -- SBC -- Firewall -- Internet -- Microsoft Teams Cloud -- Internet -- Teams User.
This worked up to R82. And I can't find anything in the release notes and admin documentation that anything regarding NAT has changed.
The behavior we see in debugs and traffic analysis is that the SBC and the Teams Cloud setup a call via and encrypted SIP channel. The firewall does not inspect this traffic and the SBC is configured to use the public IP address in the SIP negotiations. From the traces on the SBC we see this still works fine.
Then you get the 2 UDP audio streams, one outbound and one inbound for the 2-way audio, and here is where it goes wrong.
The firewall translates the outbound UDP traffic, replacing the SBC IP address with the public IP and it changes the source port (say 8790) to something in the 10,000 to 60,000 range as per documentation (say 10400). The destination port 50300 and is unaltered.
The inbound UDP connection from the Cloud to the SBC public IP comes in from the same Cloud IP and source port 50300, but towards the original port 8790 as this was agreed in the SIP negotiation, but the firewall does not recognize this connection and does not forward this connection to the SBC.
I see 2 Accept logs with NAT translations in the log:
UDP SBC_IP:8790 -> MS_Cloud_IP:50300 -- Firewall -- SBC_Public_IP:10400 -> MS_CloudIP:50300
UDP MS_CloudIP: 50300 -> SBC_Public_IP:8790 -- Firewall -- SBC_IP:8790
This second connection we see it in the logs, we see it in a capture on the WAN interface of the firewall but we never see this traffic on the DMZ interface towards the SBC. Even though it matches the inbound rule and Static NAT translation in the policy.
We temporarily changed the outbound Hide NAT to a Static NAT and now the source port is not translated and the traffic from the MS Cloud back to the SBC seems to be automatically accepted because of this session is known to the firewall(?). We don't see a 2nd log anymore for the inbound Static NAT which is still higher in the NAT policy. Pre-R82 we also had the 2 logs per call and the source port changing and it worked fine.
I hope the story makes sense to anyone.
My best guess is that the firewall with R82 is now somehow relating or recognizing the connection from the MS Cloud to the original SBC UDP port and not forwarding it because it expects a connection on the port number it changed it to. Even if there is an inbound Static NAT rule above the Hide NAT telling it to forward the traffic to the SBC.
