CaptivePortal - connection to URL slow after logon
-
Hi Guys,
in version 2.3.1 we see a large amount of time (5-10 sec) which a site needs to load, after a successful logon on the CaptivePortal.
After logging in, you see the browser trying to connect to the original url and you have to wait a bit.
When you open another tab and open another site in the meanwhile, it loads instantly - the request of the original site is still processing.btw: Setting the parameter "After authentication Redirection URL", you are redirected instantly to this site after the logon process.
How can I debug this? Or do you have some other suggestions ?
We are using RAIDUS as CaptivePortal Authentication DB.
greetings
-
I'm not sure if this is much help to you, but in case someone digs into this, these might be pointers to someone, so I'd like to weigh in:
When I evaluated pfSense as a captive portal for us, I noticed this too. I was running 2.3 at the time, inside an ESXi.
What I did find: Opening the same site / connecting to same IP automatically after login then before login takes a long time. Meanwhile, traffic to other servers on same client flows normally.
Steps to reproduce:
1. Open website on server 1.2.3.4
2. get redirected to captive portal
3. log in successfully on CP
4. pfSense redirects you to 1.2.3.4, page takes long time to load
5. meanwhile, open page to 9.8.7.6 in parallel tab, opens instantlyI did see some dropped packets in the firewall log that would explain this, but not why they were dropped. They matched the default drop, so they had to be out of state. My guess (and this is not an educated guess, just specultation) is that the client reused the connection from the first contact (which got redirected to CP), but pfSense already closed that one. Packets are out of state, get dropped, until the client timeouts the connection and builds a new one. New connections (in parallel tab) go through normally.
Since I use "After authentication Redirection URL" anyway and this is not a site that a user would normally open before auth, I did not investigate this further to drill down if this is an issue from client or pfSense, or even if my assumptions are correct.
But this might help someone investigating.