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

Unexpected VPN Disconnections on FortiGate 60E

Hello,

 

I've recently deployed a FortiGate 60E at our branch office and have been experiencing intermittent VPN disconnections. These disconnections are causing disruptions for our remote workers, especially when they are accessing shared resources on our intranet.

You can also check this - https://community.fortinet.com/t5/Support-Forum/Fortigate-AP-RADIUS-Authentication/m-p/19493splunkcourse

 

Here are some details:

  • Firmware Version: v6.4.3
  • VPN Type: IPsec
  • Average Number of Concurrent Users: 15-20
  • Disconnection Frequency: Approximately 2-3 times daily, lasting for 5-10 minutes.

Initial diagnostics don't indicate any apparent issues with bandwidth or the physical network. I've also checked for IP conflicts and found none.

  1. Has anyone experienced similar issues with the FortiGate 60E or other models?
  2. Are there any specific logs or diagnostics that could shed light on the root cause?
  3. Could this be related to any known firmware bugs or configuration nuances?

 

Thank you in advance!

Emma Wilson
Emma Wilson
1 Solution
ede_pfau
SuperUser
SuperUser

Could this be related to any known firmware bugs or configuration nuances?

Yes, of course.

The firmware version you are using is quite old. Besides, it was just the 3rd patch to the (then) new 6.4 branch.

Later, this version gained more and more stability with further patches. The current one is v6.4.14.

So, first thing on Monday for me would be to upgrade to the latest patch level, and watch out if that gets rid of the problem.

Which, btw, is not common. 5-10 minutes of a breakdown is intolerable IMHO.

 

Diagnostics could help (even with the help from the forum). So, during the next outage, open the CLI and run

"diag sys top"

 

This will display a table of processes, sorted by CPU load. If you press "m" while it's running, it will be resorted by memory usage. Take screenshots and post them here, maybe it'll denote something.

 

Of course, IPsec VPN is very sensitive to dropped packets or other interruptions on the WAN line. The tunnel would have to be rebuilt after each interruption. Using SSLVPN might help in case of a very "noisy" and unreliable line, as it is working on a different protocol (namely, HTTPS). It's got other disadvantages though.

 

To speed up an IPsec tunnel rebuild, you could create blackhole routes. You can find some posts on this in this forum. This is easy to implement, doesn't cost any resources and is quite effective. But, it will only cure the symptom, not the root cause.

To sum up, I would start with upgrading.

Ede Kernel panic: Aiee, killing interrupt handler!

View solution in original post

Ede Kernel panic: Aiee, killing interrupt handler!
2 REPLIES 2
ede_pfau
SuperUser
SuperUser

Could this be related to any known firmware bugs or configuration nuances?

Yes, of course.

The firmware version you are using is quite old. Besides, it was just the 3rd patch to the (then) new 6.4 branch.

Later, this version gained more and more stability with further patches. The current one is v6.4.14.

So, first thing on Monday for me would be to upgrade to the latest patch level, and watch out if that gets rid of the problem.

Which, btw, is not common. 5-10 minutes of a breakdown is intolerable IMHO.

 

Diagnostics could help (even with the help from the forum). So, during the next outage, open the CLI and run

"diag sys top"

 

This will display a table of processes, sorted by CPU load. If you press "m" while it's running, it will be resorted by memory usage. Take screenshots and post them here, maybe it'll denote something.

 

Of course, IPsec VPN is very sensitive to dropped packets or other interruptions on the WAN line. The tunnel would have to be rebuilt after each interruption. Using SSLVPN might help in case of a very "noisy" and unreliable line, as it is working on a different protocol (namely, HTTPS). It's got other disadvantages though.

 

To speed up an IPsec tunnel rebuild, you could create blackhole routes. You can find some posts on this in this forum. This is easy to implement, doesn't cost any resources and is quite effective. But, it will only cure the symptom, not the root cause.

To sum up, I would start with upgrading.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Emma02
New Contributor II

Thanks for the solution!

Emma Wilson
Emma Wilson
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors