Site to Site VPN configuration suggestion

[Ivan_Kusturic]

Hello everybody,

We have a customer with topology like this:

They have established VPN tunnels between Cisco ASA (will be replaced with FirePower as on image above) and remote peers (different devices). Current configuration is such that ASA has all private IP addresses and NAT to public IP address used for VPN peering is being done on CheckPoint GW.

They reported few issues after upgrade from version 77.30 to version 80.10. Also, I have read that it's not best design decision to have NAT configured like this in a S2S VPN configuration.

What are your thoughts on this? Do you have any suggestions on how it should be done "properly"?

Thank you all in advanced,

Ivan

[PhoneBoy]

What kind of NAT is being done on the Check Point for the VPN gateway, static or NAT?
What specific configuration on the Firepower has been done to account for the NAT?

[Ivan_Kusturic]

There is static NAT on CheckPoint, and identity NAT on ASA (current device in network - will be replaced with FirePower).

[PhoneBoy]

What logs do you see on the Check Point related to the IPSEC tunnel?

[Ivan_Kusturic]

I can post you those later, but could you give me your opinion regarding VPN design - specifically, VPN peer behind NAT CheckPoint? Pros and cons.

[Ivan_Kusturic]

Any comments?

[Timothy_Hall · Accepted solution]

As long as the static NAT address for the Cisco implemented by the Check Point is a unique routable address (i.e. not the firewall's external NIC address with attempted port forwarding for ESP/50 & IKE/500) it should work fine.

However due to intervening NAT between the Cisco and the Remote Peer, NAT Traversal (NAT-T) will be active on UDP port 4500.  NAT-T is essentially a double encapsulation to keep the intervening NAT operation from violating the ESP packet's digital signature.  This increases overall packet size thus reducing the amount of tunneled data that can be carried per packet, and causes some additional processing overhead as well.  Intervening NAT should be detected by the peers during IKE Phase 1 (packets 3 & 4) and NAT-T should start automatically, just make sure both sides have support for NAT-T enabled.

This kind of setup can also cause issues if the Cisco tries to use its externally-facing IP address as the IKE Peer ID, which then does not match the actual source IP addresses appearing on its IKE packets due to the NAT.  This can easily be rectified by adjusting the IKE peer settings.

What I would suggest is giving the Cisco its own interface on the Internet "dirty segment" with its own directly-assigned Internet-routable IP address.  The backend interface would then be attached as a DMZ on the Check Point.  This setup avoids the two issues listed above, and as an added bonus the Check Point can inspect traffic in the clear before it is encrypted and after it is decrypted by the Cisco.  There would of course be a performance impact on the Check Point but you would gain some valuable traffic visibility.

Ideally you could just put the Cisco "side by side" with the Check Point with its own direct Internet-routable interface and the inside interface directly on the inside, but you will have to watch out for asymmetric routing conditions on traffic trying to head to the Internet and/or VPN tunnel.  Some NAT or Policy-Based Routing may be needed to avoid this.

[Ivan_Kusturic]

Timothy, thank you very much. I appreciate this.