IPsec VPN disconnection

Is one of the end points dynamic DNS entry? If so the IP address may have changed, and the far end wasn' t aware of this change. The only way I know to fix that (as it occurs) is to change the address on the static end, then reassign the same DYNDNS name. The FGT will refresh the DNS entry and the tunnel should wake up once again. Newer versions of code take care of this relatively seamlessly. Hope that helped.

My first thought was " no dead gateway detection" . Here over in Tika-Tuka-Land Germany we build a lot of DynDNS VPNs. And to make things more interesting, the ISPs lease out public IPs for 24 hours only. So your tunnel will break once in 24 hours 100% of the time. Without hello packets/ping targets on the originating side you couldn' t run VPNs here. @Francesco: maybe you could get the " VPN Guide" from docs.fortinet.com for your FortiOS version and have a look at the phase1 parameters, especially DPD and NAT keepalive.

everything is bigger and better in the States... My remark is true for ADSL dial-up internet access only - which is the most common line type here. It' s meant to prohibit running servers on DSL lines. If you want to you can get ' business grade' SDSL lines with fixed public IPs. Price will be ~10x compared to ADSL.

Thanks for your answers. It' s not a dydns problem, both IP address are static IP. When the link goes down, the only way to reconnect is to reconfigure the VPN Im' using a route based VPN.

3 ideas: 1. as I see it the tunnel is dropped (for whatever reason - maybe there is noise on the line and 1 packet is lost -> tunnel re-negotiation) AND the other side is not aware of it. If the remote end still has " tunnel up" it will refuse to negotiate a new SA. The feature to assure that the tunnel is dropped on both ends is DPD. It will send hello packets (pings) over the tunnel, and will tear down the SA if they are not answered (in debug: ' R-U-there' ). Make sure that DPD is active on both ends. 2. There is another option called ' NAT keepalive' which will keep the session alive in the NAT table IF the tunnel crosses one or more NAT devices - which is not always the case. I' ve never had to tweak this setting yet. It will only come into play if there is no payload traffic at all over the tunnel for a couple of minutes. 3. from the CLI, there is one other option called " auto-negotiate" . It is used to bring the tunnel up at all times even if there is no traffic. Normally, the first packet(s) will trigger the SA nego and tunnel buildup. With this parameter enabled, the Fortigate will establish the tunnel immediately. (Rarely used IMHO.) Anyway, have a good reading in the IPSec VPN Guide. The documentation has vastly improved over the year and the Guide has many common examples and explains the parameters in detail. If you follow the text closely you will even find all the mismatches/errors between text and diagrams (when I do I send a mail to docs@fortinet.com and they' ll correct it pretty soon).

Hi There, I was looking for point number 3

config vpn ipsec phase2-interface edit <phase2> set auto enable end

I solved it by using the rocampo solution. Disabling " Dead peer detection" in Phase 1 on both Fortigates. Thanks Francesco

that' s not a solution but a work-around (as a dear fellow poster pointed out here some time ago). DPD works like this: some sort of ' ping packets' are sent out over the tunnel and are answered by the remote FG. As soon as multiple pings are not answered, the sending FG knows that the tunnel is down. And the remote FG knows (from not receiving requests) that the tunnel is down as well. DPD then discards the SAs involved and tears the tunnel down. From this ' virgin' situation the tunnel can be re-negotiated immediately, either automatically or when receiving the first data packet(s). Now you have noticed that disabling DPD keeps the tunnel up. I conclude from this that the DPD ' pings' (' R-U-there' packets) either don' t come through or some are lost during the transmission. Plus some failure to invoke the automatic tear down and re-negotiation of the tunnel. And this failure has a reason which still is unknown. It could be that apparently DPD is configured on both sides BUT one side didn' t ' take' it, that is, DPD is not active on one side. Then the whole DPD mechanism will fail. Without DPD I cannot imagine that tunnel re-negotiation will be quicker or smoother than with DPD. What do you observe when the tunnel is down now?