Fortigate firewall intermittently blocking traffic from Apple iPhone / iPad devices.
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.
