Hi,
I have small issue,
Imaging you have a IPSEC tunnel in interface mode.
Before the tunnel is up, someone pings an IP on the other side, and because the tunnel is not yet up, the default route sends it to wan1 (Internet), no answer of course.
Then the tunnel comes up and populates the routing table, but still the pings are sent to WAN1 because the session is already established with WAN1, is there a way to re-evaluate the sessions when something happens in the routing table ?
FCNSA, FCNSP
---
FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30B
FortiAnalyzer 100B, 100C
FortiMail 100,100C
FortiManager VM
FortiAuthenticator VM
FortiToken
FortiAP 220B/221B, 11C
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.
Remember that the default route will only be used (or of concern) if you do not have any information about the destination network. That is not the case with VPN proteced networks - usually (99.9%) they use an IP range from RFC 1918.
I am using blackhole routes for some time now to prevent VPN-internal traffic to follow the default route.
For convenience, I attach the 'blackhole routes all RFC1918.bcmd' file. It creates bh routes for all private networks which are listed in RFC1918. Running the script will not overwrite any existing routes or override them. Just in case there is no matching route the bh route will kick in.
(I have to rename the script to bla.bcmd.txt to be able to upload it...)
In System > Config > Advanced, load the above script from my post. It will install black hole routes for all private (RFC1918) networks, like 192.168.x.y., 172.16.a.b, 10.p.q.r etc.
How it works:
While a route-based VPN has the tunnel up, it's route will be used. If the tunnel goes down (for whatever reason) the black hole route will be used (it's distance is higher than any useable real route - 254). This will discard tunnel traffic - no data will leak via the WAN interface and no session will be created. When the tunnel is renegotiated it's route can be installed immediately, with no delay, and a session established.
These black hole routes cannot do any harm; you can leave them installed. In fact, they should be part of the default configuration (factoryreset)...there cannot be any route for one of these networks which is less important.
Bogdan,
glad this helped to solve your problem. It's not immediately apparent what happens in your setup when a new dial-up tunnel gets up, interrupting all other established tunnels. I can only hope your post can be easily found...
I totally support your opinion that these bh routes should be implicitly active. Partly, FTNT has followed that path: if you create a VPN using the wizard, bh routes are created for the private network range specified. So, not all.
Sorry for being late to the show...
What if you have a default route through the tunnel and the underlying connection (internet) also uses a default route in order to establish basic IP connectivity? You can't add another default blackhole route with higher distance because the WAN connection's default route will always prevail. Likewise you can't configure specific blackhole routes for the private networks behind the tunnel because they would always prevail as they are more specific than the default route, and all traffic across the tunnel would be blackholed.
It looks like the wizard generates a host route for the VPN gateway... the caveat here is that we are using DDNS, hence no static IP. Example: [size="2"]S* 0.0.0.0/0 [5/0] is directly connected, VPN_HQ[/size] [size="2"] [5/0] via 192.168.178.1, wan1 <--- This default route remains when VPN_HQ is down[/size] [size="2"]S 10.0.0.0/8 [254/0] is a summary, Null <--- This would always block 10.0.0.0/8[/size]
Thanks,
Marki
Regarding session re-evaluation feature, I have encountered this feature in firewall policy config changes.
E.g., if application control utm is enabled or a specific application ID is enabled/disabled, any existing sessions would be re-evaluated for pass/block app control utm status.
Not so familiar with IPSEC vpn + route changes/session re-evaluation setup though.
However, I found the following documentation on route changes and session re-evaluation:
config system interfaceedit <interface_name>set preserve-session-route {enable | disable}next
Just open a customer ticket support if your network setup and sessions aren't behaving as expected (e.g., if session should be re-evaluated based on some criteria, config or policy, etc.).
It could be another new cli option need to be added to accommodate the desired behavior.
Also tunnel route changes could be common, and re-evaluating sessions are expensive operation if there are thousands of entries.
A simple network config that is easily replicable would greatly help when investigating the support ticket.
Thanks.
I do the same thing as ede with minor addition all of the test networks, 127 and mcast . Technically the latter 2 should never be route as destination but just encase. This along with ede cover all possible rfc and any martians networks
Than for any rt-base vpn destinations, I install the exact match by prefix and thru the correct vpn-gateway. All traffic will 1> go thru the vpn or 2> if the vpn is down no operative, hit the null interface for the blackhole
No evaluation issues or sessions issues since the traffic will never have a session entry.
No
PCNSE
NSE
StrongSwan
Thanks guys,
I will test this later today.
FCNSA, FCNSP
---
FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30B
FortiAnalyzer 100B, 100C
FortiMail 100,100C
FortiManager VM
FortiAuthenticator VM
FortiToken
FortiAP 220B/221B, 11C
It works perfectly, thanks for the help guys!
FCNSA, FCNSP
---
FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30B
FortiAnalyzer 100B, 100C
FortiMail 100,100C
FortiManager VM
FortiAuthenticator VM
FortiToken
FortiAP 220B/221B, 11C
Please tell me the exact solution as Iam facing the same problem.
In System > Config > Advanced, load the above script from my post. It will install black hole routes for all private (RFC1918) networks, like 192.168.x.y., 172.16.a.b, 10.p.q.r etc.
How it works:
While a route-based VPN has the tunnel up, it's route will be used. If the tunnel goes down (for whatever reason) the black hole route will be used (it's distance is higher than any useable real route - 254). This will discard tunnel traffic - no data will leak via the WAN interface and no session will be created. When the tunnel is renegotiated it's route can be installed immediately, with no delay, and a session established.
These black hole routes cannot do any harm; you can leave them installed. In fact, they should be part of the default configuration (factoryreset)...there cannot be any route for one of these networks which is less important.
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 |
---|---|
1547 | |
1031 | |
749 | |
443 | |
210 |
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.