Helpful ReplyHot!Re-evaluate sessions

Author
Selective
Expert Member
  • Total Posts : 2744
  • Scores: 119
  • Reward points: 0
  • Joined: 2007/07/03 10:44:56
  • Location: Gothenburg - Sweden
  • Status: offline
2015/02/25 10:01:31 (permalink)
0

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 ?
#1
emnoc
Expert Member
  • Total Posts : 5860
  • Scores: 387
  • Reward points: 0
  • Joined: 2008/03/20 13:30:33
  • Location: AUSTIN TX AREA
  • Status: online
Re: Re-evaluate sessions 2015/02/25 11:12:24 (permalink)
0
I never seen that behavior but the forward route table should send packet if the route exists. BCPs from fortinet suggest for route-based vpns, that you install a 2nd blackhole route for this exact reason and to keep leakage at bay
 
i.e
 
route#1 VPN-Tunnel admin dist 1
route#2  blackhole admin dist 250
 
 

PCNSE 
NSE 
StrongSwan  
#2
Selective
Expert Member
  • Total Posts : 2744
  • Scores: 119
  • Reward points: 0
  • Joined: 2007/07/03 10:44:56
  • Location: Gothenburg - Sweden
  • Status: offline
Re: Re-evaluate sessions 2015/02/25 11:40:53 (permalink)
0
I agree on the security aspect,
 
However, my main concern is that the traffic is not routed to the right destination. I have seen this behavior on and off since FortiOS 3.0. I can probably fix it by using policy based routing, but that´s not a good solution in the end.
#3
Dave Hall
Expert Member
  • Total Posts : 1724
  • Scores: 176
  • Reward points: 0
  • Joined: 2012/05/11 07:55:58
  • Location: Canada
  • Status: offline
Re: Re-evaluate sessions 2015/02/25 12:43:44 (permalink)
0
Maybe something with route-maps? 

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
#4
ashukla_FTNT
Silver Member
  • Total Posts : 87
  • Scores: 7
  • Reward points: 0
  • Joined: 2015/02/02 04:25:16
  • Status: offline
Re: Re-evaluate sessions 2015/02/25 23:17:05 (permalink)
0
Clear text session can't be re-evaluated to tunnel interface. I am not sure what is coding level challange/logic but this is the case.
This is also the same case with Juniper Netscreen/SRX.
 
As emnoc mentioned we need to create a blackhole route with higher AD than vpn route for these two advantage:
1) Security aspect 
2) There will be no session created when the vpn is down ( so no session with wrong interface and no need or session re-evaluation)
 
As soon as the vpn route comes up correct session will be created (as vpn route will be preferred over blackhole route)
 
#5
Selective
Expert Member
  • Total Posts : 2744
  • Scores: 119
  • Reward points: 0
  • Joined: 2007/07/03 10:44:56
  • Location: Gothenburg - Sweden
  • Status: offline
Re: Re-evaluate sessions 2015/02/25 23:48:20 (permalink)
0
ashukla
Clear text session can't be re-evaluated to tunnel interface. I am not sure what is coding level challange/logic but this is the case.
This is also the same case with Juniper Netscreen/SRX.
 
As emnoc mentioned we need to create a blackhole route with higher AD than vpn route for these two advantage:
1) Security aspect 
2) There will be no session created when the vpn is down ( so no session with wrong interface and no need or session re-evaluation)
 
As soon as the vpn route comes up correct session will be created (as vpn route will be preferred over blackhole route)
 




Ok, thank you, so I guess I need to:
 
1. Increase "Distance" for my 0.0.0.0 route to let´s say 100
2. Set a blackhole routing for x.x.x.x to let´s say 99
3. Leave the distance for my VPN net x.x.x.x to 10 (default).
 
This way the session will be caught at the blackhole routing when the vpn is down and it won´t reach my default route as it has a higher distance ?
 
 
 
#6
ashukla_FTNT
Silver Member
  • Total Posts : 87
  • Scores: 7
  • Reward points: 0
  • Joined: 2015/02/02 04:25:16
  • Status: offline
Re: Re-evaluate sessions 2015/02/26 00:00:46 (permalink)
0
Selective
ashukla
Clear text session can't be re-evaluated to tunnel interface. I am not sure what is coding level challange/logic but this is the case.
This is also the same case with Juniper Netscreen/SRX.
 
As emnoc mentioned we need to create a blackhole route with higher AD than vpn route for these two advantage:
1) Security aspect 
2) There will be no session created when the vpn is down ( so no session with wrong interface and no need or session re-evaluation)
 
As soon as the vpn route comes up correct session will be created (as vpn route will be preferred over blackhole route)
 




Ok, thank you, so I guess I need to:
 
1. Increase "Distance" for my 0.0.0.0 route to let´s say 100
2. Set a blackhole routing for x.x.x.x to let´s say 99
3. Leave the distance for my VPN net x.x.x.x to 10 (default).
 
This way the session will be caught at the blackhole routing when the vpn is down and it won´t reach my default route as it has a higher distance ?
 




In route lookup prefix match happens first and prefix will be same for vpn and blackhole route so we need to make sure that vpn route has lower distance that blackhole route. 
So for vpn traffic either of the two routes will match anytime, so you don't need to do any AD change in default route.
 
 
#7
Selective
Expert Member
  • Total Posts : 2744
  • Scores: 119
  • Reward points: 0
  • Joined: 2007/07/03 10:44:56
  • Location: Gothenburg - Sweden
  • Status: offline
Re: Re-evaluate sessions 2015/02/26 00:05:18 (permalink)
0
Ok, I´ll leave the default route as 10 then.
 
Let me try this and get back to you.
 
Thank you!
#8
ede_pfau
Expert Member
  • Total Posts : 6383
  • Scores: 547
  • Reward points: 0
  • Joined: 2004/03/09 01:20:18
  • Location: Heidelberg, Germany
  • Status: offline
Re: Re-evaluate sessions 2015/02/26 01:12:44 (permalink) ☄ Helpfulby bogdan.grigorovici@nasdis.ro 2020/03/30 02:32:14
5 (2)
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!"
#9
emnoc
Expert Member
  • Total Posts : 5860
  • Scores: 387
  • Reward points: 0
  • Joined: 2008/03/20 13:30:33
  • Location: AUSTIN TX AREA
  • Status: online
Re: Re-evaluate sessions 2015/02/26 02:05:52 (permalink)
0
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  
#10
Selective
Expert Member
  • Total Posts : 2744
  • Scores: 119
  • Reward points: 0
  • Joined: 2007/07/03 10:44:56
  • Location: Gothenburg - Sweden
  • Status: offline
Re: Re-evaluate sessions 2015/02/26 03:48:21 (permalink)
0
Thanks guys,
 
I will test this later today.
#11
Selective
Expert Member
  • Total Posts : 2744
  • Scores: 119
  • Reward points: 0
  • Joined: 2007/07/03 10:44:56
  • Location: Gothenburg - Sweden
  • Status: offline
Re: Re-evaluate sessions 2015/02/26 10:12:55 (permalink)
5 (1)
It works perfectly, thanks for the help guys!
#12
ashraf.gamal
New Member
  • Total Posts : 1
  • Scores: 0
  • Reward points: 0
  • Joined: 2016/08/16 01:42:44
  • Status: offline
Re: Re-evaluate sessions 2017/03/08 05:47:34 (permalink)
0
Please tell me the exact solution as Iam facing the same problem.
#13
ede_pfau
Expert Member
  • Total Posts : 6383
  • Scores: 547
  • Reward points: 0
  • Joined: 2004/03/09 01:20:18
  • Location: Heidelberg, Germany
  • Status: offline
Re: Re-evaluate sessions 2017/03/08 07:27:36 (permalink) ☄ Helpfulby bogdan.grigorovici@nasdis.ro 2020/03/30 02:33:04
0
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.
post edited by ede_pfau - 2017/03/09 00:43:39

Ede

" Kernel panic: Aiee, killing interrupt handler!"
#14
bogdan.grigorovici@nasdis.ro
New Member
  • Total Posts : 2
  • Scores: 0
  • Reward points: 0
  • Joined: 2020/03/30 02:28:41
  • Status: offline
Re: Re-evaluate sessions 2020/03/30 02:55:26 (permalink)
0
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 !


#15
ede_pfau
Expert Member
  • Total Posts : 6383
  • Scores: 547
  • Reward points: 0
  • Joined: 2004/03/09 01:20:18
  • Location: Heidelberg, Germany
  • Status: offline
Re: Re-evaluate sessions 2020/03/30 04:43:53 (permalink)
0
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!"
#16
Jump to:
© 2020 APG vNext Commercial Version 5.5