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

Weird behaviour of Dial Up IPSec

just encountered this:

 

IPSec Dial Up does allow concurrent tunnels. To make sure it can handle each one it enumerates the tunnels. Good so far.

Though the Gui (and the FOrtimanager gui also) allow you to enter too long p1 names.

If you p1 name is too long the enumerating may fail because it cannot add the number to it anymore.

In my case this worked as longs as tunnels were enumerated with just a single digit (0-9). HOwever due to reasons sometimes they get a two digit number even though there are less than 10 concurrent tunnes active.

The two digit number failed due to above reason. Then the Fortigate either doesn't let you establish a tunnel or - if it already established one successfully tends to use this one. The resulting NAT IP Change leads straight into a problem since there is two remote gws using the same dynamic tunnel now. This is then (and correctly) considered a twin connection and the SA gets deleted due to this so the tunnel goes down...

 

Just wanted to let you know...


-- 

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

6 REPLIES 6
ede_pfau
Esteemed Contributor III

hi,

thanks for sharing.

This behavior is well known and has not changed over the years. In fact, I tried to provoke the GUI bug by specifying a name with 14 characters (yielding 10 connections), or 15 chars, which was prohibited. Using FortiOS v6.0.13.

So apparently you cannot enter a name which would leave no space for the current connection number.

 

 


Ede

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

well I had 13 chars for p1 name and this seems to leave only space for one digit of number...


-- 

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

ede_pfau
Esteemed Contributor III

Correct (see screenshot). connection0..9, and the 11th attempt will be blocked.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Toshi_Esumi
Esteemed Contributor II

So I wouldn't call it weird but limitation, which I believe from the inception of FortiGates. Not only the IPSec phase1 names (including the suffix) but also all interface names, like VLANs, are limited to 15 chars.

https://kb.fortinet.com/kb/viewContent.do?externalId=10588&sliceId=2

 

sw2090
Honored Contributor

yes it is a limitation. It is just weird that the webinterface don't care about it and also that if there is an established tunnel it get screwed by the next connection attempt.

 


-- 

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

sw2090
Honored Contributor

hm I don't mind that limit. However I don't understand why the FGT then does not limit you correctly on a dial up phase1. Since a FGT dial up allows up to 1000 concurrent connections it musst reserve 5 digits for enumration (up to 4 digit for number plus the leading "_" after p1 name) to ensure this does necer execeed 15 chars. And it doesn't do that. Neither FGT gui nor FMG does. 

Also enmueration seems to be handled like auto_increment in databases. So a number that was used once is tied to something with that vpn and will not be used for annother dial in  on the same vpn for some long time.

I haven't yet found out where that is stored or how I can reset that.

Once it exceeds the 15char limit it starts blocking like it was written above in here and only a reboot of the FGT seems to reset that.

Even with 5 chars reserved it would start blocking once it reached number 1000. Even though there are only a few active connections...


-- 

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