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

IPSec Dialup Tunnel enumeration reset?



there is an old bug in FortiOS and FortiManager that allows you to set too long Phase1 names. This can cause problems wenn the FGT runs out of space on creating new dialup instances due to enumeration.


This means: 

when you create a dial up ipsec tunnel named "dial_up1" then each dial up instance will be added with a number. So the first will bei dial_up1_0 then and so on. Now if your phase1 name is too long it can happen that this exceeds the length limit for phase1 names that is there in Fortinet. 

I do not understand why for ages fortinet did not implement handling of this limit for dial up tunnels. 
FMG seems not to handle that at all. The FortiGate does handle it for phase1 names in general but does not implement that - if it is a dial up tunnel - it has to reserve up to 4 digits (1000 conurrent possible connections) for enumeration.

Also it looks to me as if the FGT keeps enumerating on and does not flush the enumeration once that tunnel instance goes down. Instead it even caches that somewhere because even after flushing phase1 the incoming connections on that tunnel still get the same enumeration.


So how can I flush those enumerations the have FortiOS start anew at 0 (even if this means shutting down all currently dialled in instances to avoid enumeration conflicts)?


Additionally it is unfortunately impossible to simply rename the tunnel via FMG or FortiOS. In FOrtiOS you cannot at all. FMG lets you rename it in device manager but cannot roll that out because internally that means it would delete the tunnel and recreate it with new name instead of renaming it.  The only way to correct hat would be to delete all references and then the tunnel, recreate it with new shorter name and then recreate all the references...


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


Interesting points in your post. I remember I had seen somewhere in our documentation something about this and after some search internally and what is publicly available I found the one that I was looking for.

Based on the PDF document named "FortiOS_net-device_version-2020-10-28.pdf" below that is on the bottom of the KB article (I linked the PDF directly, so it will open it immediately) and on page 25 the behaviour you are describing is up to 6.4.2 and 6.2.5, after that it should not be a problem for 2 reasons.  First the limit after the underscore of the dial-up interfaces/tunnels has been increased and second some dial-up tunnels might not need to have the net-device enable and use the #set tunnel-search options (new IPsec behaviour from page 10)

The PDF is well written, I am sure you will find many interesting points about IPsec dial-up behaviour. I hope I helped you a bit with your concerns.

KB Article - 'set net-device' new route-based IPsec logic

Please mark the posts as solved if you have no further queries
Esteemed Contributor II

One thing this presentation doc is not saying the all facts is below in page 23:


"When upgrading from a FortiOSversion which does not have “net-device” setting, set net-device enable” is added to all dialup phase1."


You would expect this addition with "net-device enable" happens ONLY to dialup phase1s and the rest gets "diable" when you upgrade from older version to 6.0 or 6.2, which I don't remember which upgrade added it. The fact is this happens to ALL phase1s regardless dialup or not.

Currently after upgraded to 6.2.10 by now our all FGTs that are handling hundreds of site-to-site IPSecs each still have all phase1 config with "set net-device enable" because of the fact. I argued this "why?" through a TAC ticket or two at that time well before pandemic. But it went nowhere.