NAT changes in R82?

[RalfV]

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.

[the_rock]

Just to make sure, can you clarify what part exactly is failing? Maybe simple network diagram would help. I know couple of clients using R82 on their firewalls and have not heard any nat issues so far.

[RalfV]

It is so hard to describe and I can imagine no "normal" use case has any issues because normal NAT usage, with the source port and the source address changed works fine.

But from what we see in the logs and captures, incoming UDP traffic that does not exactly match the state of the existing outbound traffic NAT state does not get to the destination, in our case the SBC, even if it does hit an accept rule and another static NAT rule higher in the policy. Perhaps even more specific because the incoming session tries to connect on the original (pre Hide NAT) port number, but that is based on speculation.

This (with a static NAT rule) works:
1: UDP SBC_IP:8790 -> MS_Cloud_IP:50300 -- Firewall -- SBC_Public_IP:8790 -> MS_CloudIP:50300
2: UDP MS_CloudIP: 50300 -> SBC_Public_IP:8790 -- Firewall -- SBC_IP:8790

This (with Hide NAT + an inbound static) does not work:
1: UDP SBC_IP:8790 -> MS_Cloud_IP:50300 -- Firewall -- SBC_Public_IP:10400 -> MS_CloudIP:50300
2: UDP MS_CloudIP: 50300 -> SBC_Public_IP:8790 -- Firewall -- SBC_IP:8790

The 1 and 2 are the arrows in the drawing.

Note that the outbound session has the source port changed by Hide NAT. The inbound session can't be matched to a state (are the NAT states?) but it does hit on an inbound static NAT rule but the traffic never leaves the firewall to the SBC for some reason.

[the_rock]

Is this correct drawing I did? If not, let me know. To me, for any outbound connection, you just do hide nat and for inbound, static would do.

 

[RalfV]

The upper flow works. There is still a second static NAT rule configured for the inbound UDP session.

The bottom flow is not quite what happens. For the inbound traffic like the bottom session there is a static NAT configured. That static did not seem to work when the SBC communicates in the outbound direction via the Hide NAT first.

[the_rock]

Just to make sure, if sbc object configured for nat in smart console?

[RalfV]

No the SBC object itself in Smart Console does not have NAT configured.

[Chris_Atkinson]

Which JHF take were you on before and after upgrade out of interest?

[the_rock]

I see lots of entries in official jumbo doc for NAT in previous jumbos, so probably worth installing latest one, 44.

https://sc1.checkpoint.com/documents/Jumbo_HFA/R82/R82.00/R82_Downloads.htm

[RalfV]

We updated from R81.20 Take 105 to R82 Take 44 so we are already on Take 44.

[Timothy_Hall]

The alignment of R81.20 Take 105 to version R82 HFAs is Take 25.  Not saying you should revert to R82 JHFA 25, but you may want to closely review the fixes and additions related to VoIP in R82 Jumbo HFAs after Take 25.  sk164258: Compatibility of Jumbo HFA Takes between different releases

[RalfV]

We will check and review the changes. Although all the SIP/RTP traffic is encrypted so I don't think any changes related to VoIP will apply.

[RalfV]

We were on R81.20 Take 105.

[emmap]

Why do you have the ports in the NAT rules? Is the public IP you're using for the NAT shared with anything else?

[RalfV]

For the inbound static NAT rules there are indeed destination (original services) ports defined. That's more or less how it has always been setup. Perhaps because in the past we did share some public IP addresses for different published services. We don't share publics when we don't need to and for this SBC it is certainly not shared with anything else.

I think we just keep the services on the NAT as an extra precaution or something because it is actually the access rule which defines which ports are allowed.

[emmap · Accepted solution]

I suggest that this would work a lot better if you just did a static-NAT for both inbound and outbound without specifying ports. Leave the port filtering to the security policy. That way there will be no source port changes made by the gateway.

[the_rock]

Might be worth TAC case, just to make sure something trivial was not missed.

[the_rock]

Hey mate,

Were you able to sort this out?

[RalfV · Accepted solution]

Hi @emmap @the_rock @Timothy_Hall @Chris_Atkinson , thank you all for taking the time to help.

We are going to change the NAT rules to 1 static as suggested by @emmap in this post. The way it was built should probably not have worked in the past and as it is such a niche use case and hard to troubleshoot I'm just going to stop investing our time in it.

[the_rock]

Fair enough.