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
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
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.
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
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.
Thank you i will test and reply.
NSE 8
NSE 1 - 7
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 !
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)
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1712 | |
1093 | |
752 | |
447 | |
231 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.