Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
sw2090
Honored Contributor

[solved] IPSec tunnel does not automatically reconnect

Hiho,

 

I keep encountering this problem and I could not yet find a solution for it.

We have several IPSec Tunnels from our FGT here to FGTs on Sites and more.

They all work fine so far but from time to time (probably due to network outages) some drop down.

This creates a SNMP Trap which rises a notification to us as it should.

Since most tunnels are redundant anyhows the fallback (via prio based routing) hits in then as it should.

Problem is that the tunnels do not come up again automatically then. If I log into the corresponding FGT or our FGT (other end of the tunnel) and use the web gui or cli to make it bring up the tunnel again it come up at once and without any issues.

 

How can I make either FGT to autmatically reconnect its IPSec Tunnels once they have dropped down?

 

cheers

Sebastian

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
3 REPLIES 3
sw2090
Honored Contributor

hmkay I think I solved that myself now.

 

In Fact the tunnels do not drop down. Just the phase2 goes down due to SA TTL outrun and the tunnel not having traffic (because it doesn't renegotiate p2 then but would do if there is traffic again). This is default behaviour in FortiOS obviosly (official support docs read that). To avoid that you have to enable the auto negotiation for the tunnels p2 on one end. In 5.4 this can be done via CLI or Web-Gui.

This will renegotioate the p2 SA every 5s and with that keep p2 up.

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
ede_pfau

you're quick! That is indeed the setting in phase2-interface, "set auto-negotiate enable". Basically, this will trigger a key renegotiation some time before the keylife expires. In case of a line interruption the phase2 negos are started automatically so that the VPN will be ready to transport data.

 

You might have a look into the "set monitor <phase1name>" setting in phase1. This will monitor a second tunnel and create a backup if the monitored VPN is down. Costs less resources and keeps the table more tidy as no unused tunnels appear as 'up'.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
sw2090
Honored Contributor

yes that is what it does :)

set monitor <> might be something to consider for future. Thx for the advice! 

 

thus atm we have redundand tunnels with priority based routing (alas where redundancy is possible).

That works fine so far just the "supended" tunnels creating smtp traps was a bit annoying for it had the tunnels pop up as down in our monitoring ;)

 

I've now set autonegotion to on on all our FGTs for all the IPSec tunnels through our FMG and it seems to work so far.

-- 

"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Labels
Top Kudoed Authors