cancel
Showing results for 
Search instead for 
Did you mean: 
Post a Question
Vladimir
Jade

Gateway behind NAT. What limitations am I to be aware of?

Hi,

I am working with the client who insists on hiding their CP cluster behind ASAs.

External interface will be in RFC 1918 range.

I've used this setup before in the lab environments, but would like to hear from you if there are any gotchas and particulars that I should be aware of.

ASAs will supply Static Nat from one of the public IPs to the VIP of the cluster and, should the need arise, to any hosts located in DMZs.

I am a bit concerned with S2S and remote access VPNs and am trying to figure out what else may be impacted.

Thank you,

Vladimir

Tags (1)
7 Replies

Re: Gateway behind NAT. What limitations am I to be aware of?

Hi Vladimir,

While this setup is not as common these days it was fairly common at one time.

It's simply a matter of having inside and outside firewalls with a DMZ in between.

The internal firewall should route and not NAT to the outside firewall, so don't tick the hide internal networks behind the gateway IP address.

Having to config different firewalls can be a pain and making sure you have the correct rules on both takes some work but it's very doable.

Your right there are a few limitations when it comes to VPN's. You're going to need to NAT-T IPSec traffic if you are terminating on the internal firewall. SSL VPN (we should really be calling TLS VPN these days) should be fine coming in over 443 the rules just need to be in the ASA to allow it.

Jamie.

0 Kudos
Vladimir
Jade

Re: Gateway behind NAT. What limitations am I to be aware of?

Jamie,

Thank you for detailed reply.

Can you tell me what will the downsides of using “hide nat “ on CP behind ASA will be for the egress traffic?

Additionally, I believe I may have to specify in the VPN properties of the cluster the public IP that the ASAs will be natting cluster’s VIP to.

vlad@eversecgroup.com

+1.973.558.2738

0 Kudos
Oliver_Fink
Nickel

Re: Gateway behind NAT. What limitations am I to be aware of?

I do not see problems with SSL VPN, too. We have one customer who uses NAT in front of the firewall as part of a redundancy concept of the internet provider with leased line and LTE as backup. This leads to massive problems with IPsec VPNs, especially with third party peers. We will see if everything works when switching to the new provider in two weeks. Will be fun, I guess.

By the way: Check Point's debugging tools for VPN are awful. No possibility to have a live view on information exchange via IKE (only offline with IKEView) and existing tunnel parameters (vpn tu only shows the SPIs, not the corresponding IP numbers going through the tunnels or how much traffic is passing). Debugging is much more complex than it should (and could) be. I would like to have a monitor for IKE and IPsec like CPview with a history function.

0 Kudos

Re: Gateway behind NAT. What limitations am I to be aware of?

As long as NAT-T support is enabled on both ends of a IPSec VPN, during IKE Phase 1 packets 3 & 4 the two peers should detect that they have intervening NAT between them and then switch over to UDP 4500 (NAT Traversal) encapsulation.  Obviously if this doesn't happen for some reason it will cause problems, as the intervening NAT device scribbles in the digitally-signed IPSec packet and violates the digital signature.  The receiving peer will then discard the violated packet (usually without logging it I might add).

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

"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com
0 Kudos
Oliver_Fink
Nickel

Re: Gateway behind NAT. What limitations am I to be aware of?

"As long as NAT-T support is enabled on both ends of a IPSec VPN […]“ seems to be in conflict with sk32664 as far as I understand: "A Security Gateway will accept and support proposals for industry UDP encapsulation behind port 4500, but will never initiate a proposal, […]" with some more restrictions I am asking support services about at the moment. This is for pre-R80.10 – R77.30 for my customer.

Re: Gateway behind NAT. What limitations am I to be aware of?

Right, I was talking about R80.10 and later in regards to NAT-T.  That is a limitation in R77.30 and earlier, and I don't know of any workaround.

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

"IPS Immersion Training" Self-paced Video Class
Now Available at http://www.maxpowerfirewalls.com
0 Kudos

Re: Gateway behind NAT. What limitations am I to be aware of?

- As mentioned by Oliver Fink  R77.30 or below will only RESPOND to NAT-T requests but will not initiate them, anyway, I wouldn't think about NAT traversal at all - given Phase2/Phase1 renegotiation every other hour you risk every other hour for IPsec tunnel to go down. 

- You got the idea - define VPN properties of the gateway to present itself to the peers with its legal/translated and not RFC 1918 address, after all ASA is doing static one to one NAT, not port forwarding (look, all the Amazon AWS works just fine with RFC1918 this way). The alternative I guess would be VPNs using certificates where IP plays no role in peer identification, but it is much more complex to implement with 3rd parties.

- Take into account all the protocols requiring payload rewriting - SIP/H323/FTP/etc, in case you think to enable NAT on CP - double messing with payload (1st by CP, then by ASA) is going to go wrong.