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

[Vladimir]

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

[Jamie_Hopwood]

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.

[Vladimir]

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

[Oliver_Fink]

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.

[Timothy_Hall]

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

[Oliver_Fink]

"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.

[Timothy_Hall]

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

[Yuri_Slobodyany]

- 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. 

[genisis__]

I've got a similar setup to do, where the remote GW is behind a third-party NAT device.  The external IP of the gateway is a RFC1918 address.  The third-party would deal with the static from RFC1918 to public IP.

What I can't figure out is how we create the gw object and then add this to a community.  When adding the GW should I be specifying the public IP or RFC1918 IP?  

When doing a topo get it would clearly not have any view of the public IP.

Next assuming that the GW has to be RFC1918 address and we want this to be part of a VPN community I cannot see a way to define the Public IP anywhere.

Remote GW is running R80.20 with HFA103.

Topo:

CP > Third-party NAT > Internet > Hub Site GW > Manager

To complicate things more the Manager itself is NATed which we know works.

[Timothy_Hall]

Specify the RFC1918 address on the General Properties of the gateway/cluster object, then on the gateway/cluster object under "IPSec VPN...Link Selection...Always Use this IP Address" put the outside NAT address in the "Statically NATted Address" field.

[genisis__ · Accepted solution]

I've now setup a test solution which so far seems to work; see below:

Key:
CPMGR  = IP address of Checkpoint MGR
CVPN      = Central VPN Public IP
RVPN-P  = Public IP for Remote VPN Gateway
RVPN-I   = Private IP for Remote VPN Gateway

I've recently had to deal with a scenario where a remote CP gateway was behind a Fortigate FW. This firewall serves as a NAT device and therefore the remote Checkpoint gateway (RVPN-I) was allocated a RFC1918 address.

When creating the remote gateway (RVPN-I) clearly the topology would not be aware of the public IP, so in order to solve this you would need to do the following:
Within the remote gateway properties do the following:
Under IPSec VPN > Link Selection select 'Statically NATed IP' and enter the public IP that will be used for VPN traffic.
Note: It's important that you do not have any objects defined for the public IP or it will not work.

Fortigate configuration is below (Configuration based on v6.x version of FG code):
Inbound:
config firewall policy
edit xx
set name "Inbound to Checkpoint RVPN"
set srcintf "Internet"
set dstintf "Internal"
set srcaddr "CVPN"
set dstaddr "RVPN-P"
set action accept
set schedule "always"
set service "IKE" "ESP"
set logtraffic all
set fsso disable
next
edit xx
set name "Outbound to CVPN"
set srcintf "Internal"
set dstintf "Internet"
set srcaddr "RVPN-I"
set dstaddr "CVPN"
set action accept
set schedule "always"
set service "IKE" "ESP"
set logtraffic all
set fixedport enable <--- Important to have this enabled or it will randomise the outgoing port
set ippool enable
set poolname "RVPN-P"
set fsso disable
set nat enable
next
end

I did also have the added complication where the CPMGR is also translated as it leaves the HQMGR, but this deals with management flow traffic. Below are the rules I added on the FG to ensure management traffic worked.

config firewall policy
edit xx
set name "CPMGR to RVPN"
set srcintf "Internet"
set dstintf "Internal"
set srcaddr "CPMGR"
set dstaddr "RVPN-P"
set action accept
set schedule "always"
set service "HTTPS" "SSH" "CP_rtm" "CPD" "CPD_amon" "FW1" "FW1_CPRID" "FW1_ica_push" "FW1_ica_services" "FW1_sam"
set logtraffic all
set fsso disable
next
edit xx
set name "RVPN to MGR"
set srcintf "Internal"
set dstintf "Internet"
set srcaddr "RVPN-I"
set dstaddr "CPMGR"
set action accept
set schedule "always"
set service "CPD" "FW1 "FW1_CPRID" "FW1_ica_pull" "FW1_ica_services" "FW1_log"
set logtraffic all
set ippool enable
set poolname "RVPN-P"
set fsso disable
set nat enable
next
end

Additional I would also suggest doing the following from the RVPN-I gateway to make sure CRL retrieve works.

vpn crlview -obj <MyObj> -cert <MyCert>

If this does not work then troubleshoot as this will cause the VPN to go down.

[JozkoMrkvicka]

Hello guys,

I want to establish S2S VPN between 2 public IPs. One Check Point peer with public IP is in Azure. Second public IP is assigned to the Fortigate FW, which is simply forwarding all traffic from/to Azure towards my locally managed 16000 appliances. My 16000 appliances doesnt have internet access and all traffic which should go to the internet will go via Fortigate firewall. Fortigate firewall is simply only forwarder between public IPs and locally managed 16000 appliances.

My idea was that I will simple create VPN community where will be Azure public IP and my 16000 cluster. In Link Selection on my 16000 appliance I will type public IP of Fortigate internet facing IP (public) within "Statically NATed IP".

But my 16000 cluster doesnt try to use that public IP for VPN establishment, instead is using External interface or Main IP address of my cluster.

I am using IKEv2 and VPN traffic (IKE and ESP) from Azure is reaching my 16000 cluster, but 16000 cluster is not answering back with NATed IP. Routing is correct and is poiting to Fortigate firewall.

Any ideas where the problem is ? Is such scenario even possible ? On 16000 cluster, the public IP is not used at all (no interface with such an IP).