IPSEC VPN with Source NAT

[Atomizer]

Simple question: I want to do source nat on all trafic sent through a route based VPN tunnel and effectively hide my local clients behind one singe IP address. (Preferable one of my Public IP adresses that I don' t use anyway) I have attached a quick drawing to help explain. Is this config possible? I have set this up with succes on Cisco ASA and Juniper SSG before but now I have changed job and are faced with these Fortigates. :) Thanks in advance for any help.

[severach]

Look in the KB for IPSec Overlapping Subnets. For source NAT you' ll be only doing the instructions on one side. Policy VPN will map many to few or many to one easily. I' ve not used route VPN much to know if it is just as versatile. SNAT is also handled inside a concentrator reasonably well. With policy VPN you can SNAT to any address, your public IPs, any random public IP, any random private IP, or customer chosen IP private or public. Two NAT addresses might give you problems. If you SNAT to the public IP the phase 1 comes out of you will expose bugs in customer routers. Fortigate handles it properly. It' s some other brands that don' t. You can SNAT from your private IP to your private IP. It works but sometimes you get spotty connectivity.

[emnoc]

Atomizer, this is a very trival cfg to do and is done in the same shape & fashion as the cisco ASA to some degree You will need to enable SNAT on the FGT fwpolicies for tunnels leading from main to cust1 and cust2 You craft your src_subnet for the IPSEC-phase2 proposal, to be the SRC of the SNAT, likewise the cust1 & cust2 will have that address as their DST in their proposals. Everything else after this is just basic fwpolicy(s) , static routes to the remote ends etc........ So to answer your question, yes the config you have proposed will work. You can source that SNAT with any reachable ip_address that you present in the static-remote-routes and by fwpolicy for the services that you allow. fwiw I commonly deploy what your suggestioning , when interfacing to remote vendors and you don' t want to worry about ip_address overlaps that you commonly see in rfc1918 address. Each one of my vendors see a real public address that ' s not overlapped with any of his other customers.

[Atomizer]

Hi severach and emnoc, Thanks a lot, I got this working now :) Turned out to be a problem of the remote site. (Damn Watchguard had to be rebooted, then it started working) But thanks for clearing that this was indeed a valid configuration on the Fortigate. Still pretty scary that Fortigate support was this useless at clearing that my setup was correct.