Static NAT on ISAKMP traffic

[Richard_Lee]

Has anyone ran into issues with trying to NAT isakmp traffic out of their Checkpoint firewalls? We are trying to pass VPN traffic through our checkpoint firewalls and our static NAT is not working for this connection. A TCP dump on the outside external interface shows that the rfc1918 address is not being translated.

The router initiating the VPN connection outbound only does isakmp, but I know that if I install policy with the same public IP NAT for my internal workstation I verified NAT is working for http/https.

I've got mixed information from support saying that the ipsec blade might be trying to interfere with this traffic and then I have the NAT support team saying that this is a connections table issue. Clearing the connections table in a clustered environment will cause a major outage.

I'm going to reconfigure the VPN device with a different IP to test next. Anyone else ever run into something like this where you're trying to pass VPN traffic through the firewall?

[Timothy_Hall]

The virtual timer for UDP "connections" such as IKE/ISAKMP is 40 seconds.  If there was no NAT configured when this IKE traffic started constantly passing through the firewall, no NAT will be applied to this existing "connection" even if you change the NAT rules and install policy.  What NAT to perform is determined at the start of the "connection" when it is initially accepted, and cannot ever be changed for the life of that connection.  Your options are:

1) If you can get the IKE traffic to "shut up" for more than 40 seconds its "connection" will be expired and the new NAT config will be applied when it starts back up again.

2) Delete the IKE/ISAKMP "connection" from the state table with the fw sam command, or from the "Active" mode of the SmartView Tracker.

3) Assign a different internal IP address to the system initiating the outbound IKE/ISAKMP.  This will count as a new connection and any NAT changes should be immediately applied.

I don't think changing the outside NAT address will solve the problem for an existing "connection" like this.  Also the IPSec VPN blade should not keep this traffic from being NATted by the firewall, unless you are trying to hide or port-forward this IKE/ISAKMP traffic through the firewall's actual NIC-assigned or cluster IP address.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Richard_Lee]

Hi Timothy,

Thank you for your reply on this question.

1. I'm going to have the IKE services on the vpn device inside the firewall shut off for 15 minutes and have the external VPN device shut down as well. We'll restart the traffic and see if the NAT occurs on the firewall.

2. Will deleting the IKE/ISAKMP "connection" from the state taable with the fw sam command cause an outage to any current VPN connections that use IKE/ISAKMP?

3. Will assign a different internal IP address to the system initiating the outbound IKE/ISAKMP traffic if the above two do not apply or work for our situation.

Your comment "I don't think changing the outside NAT address will solve the problem for an existing "connection" like this.  Also the IPSec VPN blade should not keep this traffic from being NATted by the firewall, unless you are trying to hide or port-forward this IKE/ISAKMP traffic through the firewall's actual NIC-assigned or cluster IP address."

*** We're not trying to hide the service, but we're basically trying to pass the IKE/ISAKMP traffic through he firewall as a public NAT IP that we assign it in order for it to route externally. The traffic routes out an external interface on our firewall which is a clustered environment.***

[Timothy_Hall]

As long as you don't delete the IKE/ISAKMP connection for the wrong VPN peer it won't impact other tunnels.

Assigning a new public NAT address will only work for new IKE "connections".  Existing ones will not inherit the new NAT address.  You must make sure the existing "connection" tracking the IKE UDP 500 traffic is dead before any NAT changes will actually start being applied to it.

You will need to Hide NAT the IKE traffic behind a public IP address that is not directly assigned to a firewall's interface or a cluster IP address of the firewall itself, because the firewall will probably interfere with the NATing of the IKE traffic in that configuration.  You need to "pluck" another routable address from your ISP-assigned netblock and use that to hide NAT the IKE traffic instead.  Basically what Houssameddine Zeghlache‌ said.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com

[Houssameddine_1]

If you have IPSEC blade enabled on the checkpoint firewall you need to used different public IP to NAT your router.

[Richard_Lee]

We do have the IPSEC blade enabled.

So are you saying that the router should be configured with a public IP before it gets sent to the firewall?

In other words the firewall wouldn't be doing that NAT then correct?

[Houssameddine_1]

let's say your firewall has public ip 1.1.1.1, you need to do the NAT on the firewall for the router to another public IP 1.1.1.5 for example, you can't use the same public ip on the firewall.

[Richard_Lee]

Yes that is exactly what we're doing.

Internal router has rfc 1918 internal address 172.16.xxx.xxx

Publicly all internet traffic will leave as IP 1.1.1.1 and we've NAT the internal router as 1.1.1.5.

We never get a log that that shows the internal router NAT over as 1.1.1.5.

Also if I run a tcpdump on the external interface as I watch the traffic leave, I never see the NAT happen as well.

Sometimes I'll see the internal address 172.16.xxx.xxx attempt to leave to the destination on the external interface which we know will never router as well.

[Richard_Lee]

I took my laptop and configured it with the same 172.16.xxx.xxx and plugged it into the same switch port that this VPN router is plugged into. when I go out via 443 traffic I can see the NAT occur successfully.

It's baffling to see that only IKE traffic is not being NAT correctly but 443 traffic is.

[Timothy_Hall]

Is it logging any kind of "NAT rule" or "Additional NAT Rule" as rule 0 in the IKE accept log?  Please provide the full IKE logging details with IP addresses redacted as needed.

A definite long shot, but SecureXL could be the culprit.  Try disabling it with fwaccel off and see what happens.  If your firewall has more than 8 cores I'd recommend trying this after regular business hours.

--
Second Edition of my "Max Power" Firewall Book
Now Available at http://www.maxpowerfirewalls.com