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

Freezes on the IPsec Sito to Site

Hello,

 

we have a 200D in HQ and a lot of 60D branches all with IPsec Sito to Site connected in Hub and Spoke.

 

now we issue a 3 - 4 times in a day that the Tunnel do freeze (for example i see it if i am on the RDP Connection and the connection get lost and retries to do the Session and after 3- 4 Times the session is UP again.) The tunnel is always UP and i see no Errors in the Logs.

 

Do someone had similar strange behavior? its pretty annoing..

NSE 8 

NSE 1 - 7

 

NSE 8 NSE 1 - 7
1 Solution
ede_pfau
SuperUser
SuperUser

This might be caused by traffic following the wrong route.If that is the case, here's an explanation and a fix.

 

If the VPN is interrupted shortly the FGT will send out the traffic intended for the private LAN on the other side of the VPN to the WAN port, following the default route. Once this session is established it is cached in the routing cache. When the VPN comes up again, there is already a session for this traffic and so packets are sent to Nirvana.

There is a quick fix for this: if you create blackhole routes for all private networks in use (192.168, 10.x.x.x etc.) with high distance values, they will be used instead of the default route if the VPN is down. The difference is that no sessions will be established to blackhole routes, thus no route cache entries. As soon as the VPN comes up again traffic is routed through the tunnel.

To faciliate this, I've written a batch command script which can be loaded onto the FGT. BH routes are not in use normally so this can be done even as a precaution. I don't think the script is FortiOS version dependent - you'll see.

You can download it in this forum post. Scroll down to my post near the end.

Ede Kernel panic: Aiee, killing interrupt handler!

View solution in original post

Ede Kernel panic: Aiee, killing interrupt handler!
5 REPLIES 5
AndreaSoliva
Contributor III

Hi

 

who confirms that this is a VPN IPSec issue? To confirm this try to find out what IKE does meaning the tunnel:

 

diagnose debug reset

diagnose debug application ike -1

diagnose vpn ike log-filter

diagnose debug enable

 

NOTE if you have many IPSec on the device you should filter with command below this means with this command you configure a filter which is used within the debug:

 

            # diagnose vpn ike log-filter list                         vd: any             name: any             interface: any                 IPv4 source: any             IPv4 dest: any             IPv6 source: any             IPv6 dest: any             source port: any             dest port: any             autoconf type: any             autoconf status: any

 

            # diagnose vpn ike log-filter ?                         clear        Erase the current filter.             dst-addr4    IPv4 destination address range to filter by.             dst-addr6    IPv6 destination address range to filter by.             dst-port     Destination port range to filter by.             interface    Interface that IKE connection is negotiated over.             list         Display the current filter.             name         Phase1 name to filter by.             negate       Negate the specified filter parameter.             src-addr4    IPv4 source address range to filter by.             src-addr6    IPv6 source address range to filter by.             src-port     Source port range to filter by.             vd           Index of virtual domain. -1 matches all.

 

To clear at the end the filter use "diagnose vpn ike log-filter clear"

 

Such things can happen for various reason and must be not related to VPN like:

 

- keylifetime in phase1 not set correctly on both sites which means one site has the view the key is not anymore valid and the other has the view it is valid. At the end the tunnel must be refreshed.

- devices are based on dhcp ISP IP and not fix which means you are working with dyndns which means if the DHCP lease from IPS is renewed there is such a symptome you describe.

 

Try to eliminate all factors to find out to which technology the issue is related like, RDP server, ISP connection, VPN etc. etc. only if 100% it is confirmed that it is VPN only related it makes sense to investigate.

 

hope this helps

 

have fun

 

Andrea

ede_pfau
SuperUser
SuperUser

This might be caused by traffic following the wrong route.If that is the case, here's an explanation and a fix.

 

If the VPN is interrupted shortly the FGT will send out the traffic intended for the private LAN on the other side of the VPN to the WAN port, following the default route. Once this session is established it is cached in the routing cache. When the VPN comes up again, there is already a session for this traffic and so packets are sent to Nirvana.

There is a quick fix for this: if you create blackhole routes for all private networks in use (192.168, 10.x.x.x etc.) with high distance values, they will be used instead of the default route if the VPN is down. The difference is that no sessions will be established to blackhole routes, thus no route cache entries. As soon as the VPN comes up again traffic is routed through the tunnel.

To faciliate this, I've written a batch command script which can be loaded onto the FGT. BH routes are not in use normally so this can be done even as a precaution. I don't think the script is FortiOS version dependent - you'll see.

You can download it in this forum post. Scroll down to my post near the end.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Holy

 

Thank you i will test and reply.

NSE 8 

NSE 1 - 7

 

NSE 8 NSE 1 - 7
bogdan_grigorovici

ede_pfau...I cannot thank you enough.... Our Problem: RDP connections over dialup IPsec tunnels (Forticlient-Fortigate) disconnecting

Your post here and your explanations solved a major problem for our company. Trying to work remotely and to establish a lot of Dialup IPsec VPN connections (Forticlient-Fortigate) we have discovered that each time someone connected or disconnected a VPN dialup tunnel, all the other RDP sessions were disconnected and then reconnected in a few seconds. Enough however to mess up all the screens and windows. Not to mention the annoyance of getting that every minute or so. I would have never guessed that a missing route may be the cause of all this. We suspected the internet connections, the congestions and whatever else we could think of, except routes. IMO that should not have been the default behaviour of Fortigate firewalls and these routes should have been implicit. Many thanks again ! All the best !

hklb
Contributor II

Hello,

 

Which firmware do you use? (if 5.2.X, try to see if the connectivity issue appear when you apply firewall rules..)

 

Is the issue appear on all remote site in the same time ? You can try to disable the npu offload for IPSEC (on phase1, set npu_offload disable)

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