We have a Fortigate firewall in active/backup configuration running FortiOS 5.0.9.
TL;DR Firewall intermittently stops passing https packets from iPhone or iPad with message on the firewall of "no session matched".
Just posting this here in case anyone else is experiencing this odd issue.
More information
Recently one of our users noticed that they were unable to access an internal application that is essentially a web site that uses https. They can get to the initial page of the web site but not beyond it using an Apple iPhone or iPad client.
We have done a lot of testing at each stage of our network and traced the packets through the network using Wireshark and some network taps. We tap the fibre going into the firewall and we can see packets going in, however they never emerge out of the trust interface, past the initial loading of the web page.
Essentially, the packets are getting all the way through the network until they reach the firewall. A debug reveals the packets are being dropped with a message of "no session matched". All of the rules and policies that are in place allow traffic between the source and target network.
I'm unsure about any advanced features like web filtering and SSL inspection; I do not think we use them. As far as I know, we only use the firewall for normal firewall functions and do not use any of the upper layer protocol features that relate to actual packet contents.
Some observations: When the client initially opens the web site, it creates several TCP sessions between client and server which are identified by their source port numbers (all have destination of 443 for https).
Depending on which client we use this (iPad, Windows, Android, etc) the number of initial sessions that are opened differs.
Based on my testing, an Apple iPhone or iPad consistently opens 6 TCP sessions during the initial loading of the web page. If the user tries to do anything else, such as click on a link within the web site - the firewall appears to block any additional traffic in excess of the 6 sessions it already knows about. We see the client send SYN packets to initiate additional sessions, but they are never responded to with an ACK packet. This causes the client to retransmit until eventually the server sends RST/ACK and the sessions time out.
As far as I am aware, we have no TCP session limits in place on our firewall policies - but the behaviour exhibited is as if there is. We see this behaviour mainly on Apple iPhone or iPad. Windows clients exhibit the behaviour if the number of TCP sessions exceeds 6, if it doesn't the application works fine.
By comparison, if we use an Android Lollipop client, it generally opens in excess of 10 TCP sessions during the initial loading of the web page and seems to be able to reuse these sessions for additional traffic as well as creating additional sessions if it needs to. All traffic being passed by the firewall as normal/expected.
It seems to me that there is something wrong with the sessions that the Apple devices create that the firewall doesn't seem to like and decides to block.
Darren.
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.
Hello Daren,
In general, when Firewall drops a session with message 'no session matched', it means that the traffic doesn't match any of the existing sessions.
Usually, this happens, when the actual session from the client is timed out on the Firewall, however, the client tries to use the same old session which Firewall blocks it with a no session matched message.
Below KB article explains similar issue:
http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD36429
Hope that helps.
Yes, this can cause the issue which you are experiencing.
Your explanation already had the cause of the issue. As the Firewall is not aware of the session(return packet, not being through the Firewall) and next consecutive requests are again passing through the firewall which is unaware of these new requests and session check doesn't allow it.
Hello Daren,
In general, when Firewall drops a session with message 'no session matched', it means that the traffic doesn't match any of the existing sessions.
Usually, this happens, when the actual session from the client is timed out on the Firewall, however, the client tries to use the same old session which Firewall blocks it with a no session matched message.
Below KB article explains similar issue:
http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD36429
Hope that helps.
Hi Vjoshi,
Thanks for your helpful reply, it is appreciated.
We have done some further investigation this afternoon.
It seems that when packets are going from client to server they are being routed through the firewall, however, when the replies come back on the return route they are not being routed through the firewall.
We have quite a complex network with multiple VRFs and VLANs. It seems that the packets from server back to client are finding a quicker route that bypasses the firewall.
Consequently the firewall appears to be unable to maintain TCP session state information (we have it set for stateful inspection) because it never sees the return packets and perhaps this is the key to the issue.
I'm still unable to explain why certain clients, like Android, work OK and others, like iPhones do not.
I was certainly not aware that anything had changed on our routing. Do you think such a scenario could cause this issue?
Darren.
vjoshi wrote:Hello Daren,
In general, when Firewall drops a session with message 'no session matched', it means that the traffic doesn't match any of the existing sessions.
Usually, this happens, when the actual session from the client is timed out on the Firewall, however, the client tries to use the same old session which Firewall blocks it with a no session matched message.
Below KB article explains similar issue:
http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&externalId=FD36429
Hope that helps.
Yes, this can cause the issue which you are experiencing.
Your explanation already had the cause of the issue. As the Firewall is not aware of the session(return packet, not being through the Firewall) and next consecutive requests are again passing through the firewall which is unaware of these new requests and session check doesn't allow it.
It turned out that a routing change had been made on the network so that some packets were being routed on the firewall, whilst others were being routed on one of the routers. This created an asymmetric routing scenario that caused the issue.
Once we reverted the routing change, all was working again.
Thanks very much for your assistance.
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 |
---|---|
1645 | |
1070 | |
751 | |
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.