Fortigate firewalls are stateful by design, this means that when a client behind the firewall talks to lets say Google a session is created – If all security policies are met. Google’s return traffic can automatically come back into the client, following the same path (Session) without having to explicitly have an access rule that allows that traffic. This is also very beneficial in security because the firewall keeps track of that session, makes sure all traffic is flowing on the session as it should, and will close the session if needed. When the session is closed Google cannot talk to our internal host anymore without following very specific rules that would allow communication from them.
With remote APs, Video streams, any many more (Specifically UDP streams) I see problems a lot with sessions getting created on the WAN (Default route) for RFC-1918 private subnets. When this happens internal clients – Maybe APs – cannot talk back to the controller or the UDP video encoder cannot find the decoder any more, but other clients can communicate with those devices just fine.
The reason this happens is that most of the time the IPSEC VPN tunnels or MPLS/E-LAN interfaces have static route assigned to them for getting to the other side subnets. If the physical interface or VPN interface drops then what routes exist in the routing table? Thats right – just the default which in turn sends all traffic even for private subnets out to the internet. Lets take a UDP video Stream between two locations for example -UDP never needs an acknowledgement of the traffic, so it keeps blasting traffic to the session – when the session gets created to the internet
When those interfaces or tunnels come back online all should work, and will unless traffic never stops flowing, which is where our problem lies. When traffic tries to flow when all interface routes are down, then the only route left is the default – so the session gets created on the WAN interface.
To clear these sessions and fix the issues there are a few options.
1 – clear all sessions of the firewall
2 – create session filter and only clear the sessions you need to .
There are many other reasons to clear sessions than the reason I mentioned above. So lets get to commands!
First you can show sessions on the firewall by using:
Status will show you how many active sessions you have on the firewall and List will print out the individual sessions.
When you select list you get the following information
So for this example lets check out the session created from my internal host 10.3.0.1 going to 220.127.116.11 (www.mirazon.com).
So we see that just by going to http://www.mirazon.com it opened 6 session, these are all going to the same destination IP/Port but coming from different source ports. Option 1 was we could clear all sessions from the firewall – the command to do that is:
diag system session clear
In this example, lets say I want to clear only sessions going to IP 18.104.22.168. We need to create a session filter and then clear only those. Here are the following options on creating filters
Lots of options – one of the coolest in my opinion is matching on Protocol! But in this case lets match by destination IP.
Thats it! now we have cleared all sessions going to that IP.
A few things to note – The firewall will clear out a session if it does not see a keepalive. It will do that every 3600 seconds by default – this means if a voice call is going on through the firewall then it might close the session after 3600 seconds – this can be a big problem. The “dia system session list” is a great way to find a session and see when it will expire. Great way to troubleshoot – you can also use the GREP keyword to help find exactly what you want.
Use caution with the diag sys session clear command, as it is applied globally, not just in the VDOM you execute from. If clearing sessions based on an overly broad filter, be sure to set the VDOM index number as part of your filter definition (vd=). You can find the VDOM index number using diag sys vd list. Also consider using the diag sys session list command before running the clear command, just to visually inspect in advance what you’re about to clear.
I give this advice because I once intended to clear all TCP sessions from a non-prod VDOM, but I failed to set the VDOM index number, and ended up clearing all TCP sessions from all VDOMs simultaneously. Not an ideal situation in an enterprise production environment.
Thanks for the comment and info!