How to access a VPN via NAT?

[Robert_Gordon]

I have an existing IPSec VPN from our R77.30 firewall over the Internet to a third-party firewall at the other end. Behind our firewall my users are on a private network. They connect to the other end via a proxy server located on one of our firewall network segments. All this working just fine.

Now we have a request for a new application that cannot be configured to go via a proxy, so has to be natted to an address on the firewall i.e. desktop -> firewall NAT -> VPN destination. I have tried many approaches and nothing works. The translation takes place ok but is not routed through the VPN. Note that our internal network is fully private and cannot route to anything other than local addresses and our firewall segments.

Any guidance & example configs appreciated.

[Kaspars_Zibarts]

Make sure that your client is part of encryption domain on both ends of the VPN. I just assumed that you have configured rules in similar fashion to existing proxy rules. That would force to encrypt traffic.

[Robert_Gordon]

The elements my side are all in the local encryption domain but I'm not sure the remote domain is relevant for a couple of reasons a) the NAT session never gets as far as even attempting to establish the vpn connection even though after NAT translation takes place the VPN destination is correctly set and b) the remote domain knows nothing about our internal networks, including the current & working proxy server private address. All VPN access is NAT translated my side to be from an external facing public IP address.

I am thinking that the VPN policy rule is checked for applicability BEFORE NAT translation and not AFTER NAT translation. If this is so, then back to the original question, how can this be made to work?

[Kaspars_Zibarts]

I might be wrong but I think you will need to define both (original and translated IPs) in the encryption domain for it to consider the traffic for encryption. Check how you have set it up for proxy that works

[Timothy_Hall]

If the traffic is not being encrypted into the tunnel at all (I assume you are seeing an Accept action instead of an Encrypt action in the logs), you have a problem with your VPN domains.  I'm assuming you are not trying to use route-based VPN via VTIs and you have all the default settings in NAT Global Properties selected.  Here is the order of operations for determining whether traffic is "interesting" (to borrow a Cisco term) to a VPN tunnel:

1) Network/Firewall policy must accept traffic based on src/dst/service

2) Matching NAT rules determined for both destination and source

3) Destination NAT operation performed on packet (actual source NAT operation will happen later)

4) Gaia IP routing based on post-NAT destination - this should typically be towards the External interface

5) If packet's pre-NAT source IP is in your firewall's VPN domain AND the post-NAT destination IP is in your peer firewall's VPN domain, AND the VPN column of the rule matched in #1 is "Any Traffic" or explicitly set to the matching VPN Community, source NAT then encrypt the traffic into the matching Community tunnel of which both your firewall and the peer are members.  If any of these are not true just source NAT if applicable and forward in the clear.

Make sure that the pre and post NAT destination addresses on the VPN peer's internal network are NOT defined in your own firewall's VPN domain or encryption will not happen.  Also make sure that the destination peer's VPN domain does not overlap with any other VPN peers, use command vpn overlap_encdom communities -s to easily detect this.

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

[Houssameddine_1]

In  addition to Tim's explanation, There is  function in the firewall code called VPN tagging and it is responsible to mark the packet  to be encrypted or not. in your case you have to have The original IPs and Natted IP in your encryption domain and make sure that NAT is no disabled inside the vpn community. ask the peer to adjust your encryption domain on his side too to avoid phase 2 negotiation issues.

Thanks