Skip to main content
Holy
Holy
New Member
May 28, 2015
Solved

Freezes on the IPsec Sito to Site

  • May 28, 2015
  • 3 replies
  • 14253 views

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..

Best answer by ede_pfau

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.

3 replies

AndreaSoliva
AndreaSoliva
New Member
May 28, 2015

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
ede_pfauAnswer
SuperUser
May 28, 2015

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.

Holy
HolyAuthor
New Member
May 28, 2015

 

Thank you i will test and reply.

hklb
hklb
Visitor III
May 28, 2015

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)

Terms & ConditionsAccessibility statement