Site to Site : Local ID and NAT

Hello and welcome,

How can I force the fortigate to present himself with the public IP as the Local ID in the IKE P1 proposal ? Instead of its own private IP ?

You can' t from the fortigate itself do that; this is under the other border device control. However, you could configure a dialup VPN from that fortigate to the remote site and if th border device allow NAT traversal and/or appropiate AH/ESP protocols, you culd establish a VPN IPSec tunnel regards

The thing is, my fortigate has its external interface NAT' ed as a 1-to-1 static NAT. It' s not " masqueraded" . The thing is, when the fortigate IKE connects to the other end, it presents, in the " id" field, its private external ip, not the NAT' ed IP (which is a normal behavior). But the VPN box at the other ends refuses the IKE connection (discrepancy between remote gateway address -public- and peer id -private- presented by the remote device). Unfortunately there is no way to desactivate this checking on the remote vpn box (unlike the fortigate where one can accept ALL peer IDs). Both VPN ends have NAT-T enabled already.

Hope it can help you... I' ve configured a phase1 for a VPN policy mode (ipsec interface not selected). In the advanced I' ve defined a local ID = 10.2.3.4 (my FG real non-natted address) On the remote (non-FG) equipment I' ve configured a line like this: ike peer FG REMOTE_ID fqdn 10.2.3.4 It worked. Maybe you can change the configuration of your local and remote equipment in the same way.... Cheers

Ok I managed to get this working by specifying the peer id onto the remote equipment, which behaves just fine. @sas900av : your answer is interesting, since I tried that as well (forcing a " Local ID" IP address onto the fortigate). But, on the other side of the VPN, the Local ID was prepend by a ' @' , like @192.168.0.1, rejected by the other device which expects a pure IP address. Probably this stuff is used on non-PSK auth, which Im not familiar with.