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

Re-evaluate sessions

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

FCNSA, FCNSP---FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30BFortiAnalyzer 100B, 100CFortiMail 100,100CFortiManager VMFortiAuthenticator VMFortiTokenFortiAP 220B/221B, 11C
2 Solutions
ede_pfau
Esteemed Contributor III

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


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
ede_pfau
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
17 REPLIES 17
ede_pfau
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
jmlux
New Contributor III

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

darwin_FTNT

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 interface

edit <interface_name>

set preserve-session-route {enable | disable}

next

 

https://docs.fortinet.com/document/fortigate/6.0.0/handbook/562378/controlling-how-routing-changes-a...

 

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.

emnoc
Esteemed Contributor III

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  

PCNSE NSE StrongSwan
Carl_Wallmark
Valued Contributor

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

FCNSA, FCNSP---FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30BFortiAnalyzer 100B, 100CFortiMail 100,100CFortiManager VMFortiAuthenticator VMFortiTokenFortiAP 220B/221B, 11C
Carl_Wallmark
Valued Contributor

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

FCNSA, FCNSP---FortiGate 200A/B, 224B, 110C, 100A/D, 80C/CM/Voice, 60B/C/CX/D, 50B, 40C, 30BFortiAnalyzer 100B, 100CFortiMail 100,100CFortiManager VMFortiAuthenticator VMFortiTokenFortiAP 220B/221B, 11C
ashraf_gamal

Please tell me the exact solution as Iam facing the same problem.

ede_pfau
Esteemed Contributor III

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.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
Labels
Top Kudoed Authors