Session problem on websites (load balancing + sticky connections = state issue?)
-
I'm having issues with pfSense outgoing connections load balancing (through my 3 WAN Internet connections) and many websites that requires some sort of authentication (via a simple web/HTML form):
When you try to access the protected page you get redirected to the login form, once credentials sent you get access to the protected pages but only for a few seconds: about 20-25 second (sometimes even less but never more than a minute) after login-in the the next asked page redirects you to the login form.I've tried using the "Use sticky connections" option (located in "System: Advanced: Miscellaneous > Load Balancing") but it doesn't work either.
I've checked connections states (located in "Diagnostics: Show States") and filtered it on one the website's IP (82.165.xx.yy) for which I have the issue and they are all in "FIN_WAIT_2":
Proto Source -> Router -> Destination State
tcp 82.165.xx.yy:80 <- 192.168.0.55:55919 FIN_WAIT_2:FIN_WAIT_2
tcp 192.168.0.55:55919 -> 88.160.aa.bb:53387 -> 82.165.xx.yy:80 FIN_WAIT_2:FIN_WAIT_2-
192.168.0.55 is the LAN IP of my computer
-
88.160.aa.bb is the WAN IP of one of my WAN Internet connection
-
82.165.xx.yy is the IP of the webserver
So my guess (and it's seems to be what support@optimalnetworks.c guessed in it's topic: sticky sessions) is that, as states are "FIN_WAIT_2:FIN_WAIT_2", connections are dropped.
Side note: All three WAN connections are working just fine and, apart from that web-session issue all seems to be good. The websites aren't using HTTPS but simple clear HTTP so I can't create a rule to use my no-loadbalancing gateway group.
Edit: typo in first paragraph.
-
-
Sticky keeps an association between a client IP and a gateway so long as there are active states for that client.
In https://github.com/bsdperimeter/pfsense/commit/4573641589d50718b544b778cea864cfd725078a I added a GUI field to control the state tracking timeout so that sticky association can be held longer.
What some people do is direct HTTPS into a failover group instead of load balancing.
With sticky, what a lot of people don't understand is that the "sticky" relationship binds all connections from a client to a single WAN until all of their states expire, so in effect it changes the firewall behavior from a connection-based load balancer to a client-based one.
When sticky is enabled, you can view the source tracking table under Diag > States on the Source Tracking tab.
-
If you want to experiment with that setting, you can pull in just that one commit change using the System Patches package
-
Sticky keeps an association between a client IP and a gateway so long as there are active states for that client.
This is how I understood the sticky connections works, but as the "Show States" display no active states I think there is somewhere something that "inadvertently" prevents the sticky connections option to achieve it's goal by ending connections (thus becoming in FIN_WAIT_2): it might simply be HTTP "Connection: close" header.
In https://github.com/bsdperimeter/pfsense/commit/4573641589d50718b544b778cea864cfd725078a I added a GUI field to control the state tracking timeout so that sticky association can be held longer.
I'll give it a try…
What some people do is direct HTTPS into a failover group instead of load balancing.
In this case, the websites aren't served via HTTPS protocol.
One funny thing I found while testing: some site's backoffice where I was always "kicked" of in 3 or 4 seconds were now working just fine (or at least 10 minutes) after I added the following firewall rule just before my "load balancing" rule:
TCP 192.168.0.0/24 * * 80 (HTTP) GW_LoadBalancing noneSo my firewall rules are:
TCP LAN net * * 443 (HTTPS) GW_WanA_FO_WanB none TCP 192.168.0.0/24 * * 80 (HTTP) GW_LoadBalancing none * LAN net * * * GW_LoadBalancing noneI can't really explain how this could be of any impact as the rule #3 does the same job as the newly added rule #2.
