Re-evaluate sessions

[Carl_Wallmark]

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 ?

[ede_pfau · Accepted solution]

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_pfau]

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.

[jmlux]

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 interfaceedit <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]

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

[Carl_Wallmark]

Thanks guys,

I will test this later today.

[Carl_Wallmark]

It works perfectly, thanks for the help guys!

[ashraf_gamal]

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

[ede_pfau · Accepted solution]

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.