2.3.4 Captive Portal redirect fail after login

sheepthief

Edit: typo in subject line corrected!

Redirect after successful login fails, but browser refresh gets the page.

Or rather, it fails if using IE11, but works with Firefox. I've seen another post about this which didn't resolve the issue.

Same result whether using my custom login page, or the default pfsense one.

There's information in https://forum.pfsense.org/index.php?topic=109789.0 which leads to a bug report: https://redmine.pfsense.org/issues/6421 which suggests that it was fixed after version 2.3.1 (nginx keepalive_timeout).

However, a quick look at these files -
/var/etc/nginx-[cpzone]-CaptivePortal.conf
/var/etc/nginx-[cpzone]-CaptivePortal-SSL.conf

suggests that the fix of setting keepalive_timeout to 0 has been done only for non-SSL, ie it's still 75 in the latter file.

Sure, enough, if I switch to http login page redirect now works in IE11. Switch back to https…. fails. And I need https.

So, is there a way that I can fix this permanently? (no, I don't want to update to 2.4.0 just yet).

Derelict

What is 2.3.6?

Captive portal cannot redirect https pages without certificate errors.

Not just pfSense. No captive portal can.

sheepthief

Oops - typo - 2.3.4, not 2.3.6.

It's not a certificate error, it's a timeout. And the page I'm going to is http, not https.

And it works just fine using Firefox.

And it worked just fine under 2.1.5.

Derelict

Going to need more information. Not tracking any CP issues in 2.3.4_1. Must be misconfiguration.

Much captive portal behavior is 100% dependent on how the client (IE, Firefox, etc) decides to deal with the "internet is broken" issue.

sheepthief

I'm not sure how it can be misconfiguration.

Examples (doesn't matter whether using default CP login page or my own custom page)…

Kicking off using http://www.msn.com, with CP set to use https
Using Firefox, login page pops up, login, am redirected to http://www.msn.com
Using IE11, login page pops up, login, times out with "this page can't be displayed", hit F5, http://www.msn.com loads

Kicking off using http://www.msn.com, with CP set to use http
Using Firefox, login page pops up, login, am redirected to http://www.msn.com
Using IE11, login page pops up, login, am redirected to http://www.msn.com

Also -
/var/etc/nginx-[cpzone]-CaptivePortal.conf contains the line keepalive_timeout 0;
/var/etc/nginx-[cpzone]-CaptivePortal-SSL.conf contains the line keepalive_timeout 75;

which seems to be a smoking gun given the links mentioned in the OP.

Derelict

What, exactly, is your captive portal configuration? Please be complete and explicit.

sheepthief

Here's the xml with certain info redacted (and MAC/IP/name exceptions removed for size reasons). This particular system still has custom html but I've removed that - I have a number of 2.3.4 systems which all exhibit the same symptoms, testing using the pfsense default html shows no difference.

Oh, I just tested using Safari too, and that works, so it's related to IE11. Unfortunately I don't have any other browser versions to hand just now.

Just to re-iterate - logins actually work, but when using IE11 you have to hit F5 to get to the page originally requested, if CP is set to use https.

	 <captiveportal><redacted>redacted

			<zoneid>2</zoneid>
			<interface>lan</interface>
			<maxproc></maxproc>
			<timeout>720</timeout>

			<enable></enable>
			<auth_method>radius</auth_method>
			<reauthenticateacct></reauthenticateacct>
			<httpsname>redacted.redacted.uk</httpsname>
			<preauthurl></preauthurl>
			<blockedmacsurl></blockedmacsurl>
			<bwdefaultdn>2000</bwdefaultdn>
			<bwdefaultup>2000</bwdefaultup>
			<certref>59d4e851a8736</certref>
			<radius_protocol>PAP</radius_protocol>

			<radiusip>10.240.80.2</radiusip>
			<radiusip2>10.240.68.29</radiusip2>
			<radiusip3>10.240.144.2</radiusip3>
			<radiusip4>10.240.67.27</radiusip4>
			<radiusport>2812</radiusport>
			<radiusport2>2812</radiusport2>
			<radiusport3>2812</radiusport3>
			<radiusport4>2812</radiusport4>
			<radiusacctport></radiusacctport>
			<radiuskey>redacted</radiuskey>
			<radiuskey2>redacted</radiuskey2>
			<radiuskey3>redacted</radiuskey3>
			<radiuskey4>redacted</radiuskey4>
			<radiusvendor>default</radiusvendor>
			<radiussrcip_attribute>wan</radiussrcip_attribute>
			<radmac_format>default</radmac_format>
			<radiusnasid></radiusnasid>
			 <page><htmltext>redacted</htmltext>
				<errtext>redacted</errtext></page> 
			 <element><name>captiveportal-redacted-logo.gif</name>
				<size>5864</size>
				redacted</element> 
			<maxprocperip>32</maxprocperip>

			<radmac_secret>redacted</radmac_secret></redacted></captiveportal>

Edit: incidentally it's a configuration that has worked for me since 2.15 and before that, on about a dozen systems. Of course the custom html was updated to work with 2.3.4 but that's not a factor here. And these systems are newly build from scratch - they're not upgrades of old systems so they don't have any legacy stuff lying about in the configs.

Derelict

Well that sounds like an edge case and IE11-releated. I will take a look when I have time. But I don't have any IE11 clients to test with so no promises as to a timeline.

sheepthief

Thanks - no worries.

The vast majority of our users are on mobile devices and though I've not been able to test one myself yet I've not heard any complaints from them. The people using laptops with IE11 will be savvy enough to hit F5.

I'll dig further early next week - right now I'm working remotely and with dodgy broadband so progress is slow and frustrating.

I'll also look at updating to 2.4.0 but first I must check if the bug that stops traffic while authenticating to radius still exists as that would be a deal-breaker for me.

Derelict

That has not been corrected yet but is no worse than in 2.3.4_1. And it impacts OpenVPN, not Captive Portal. It is not a RADIUS thing, but an OpenVPN thing. I have not tested it but I would guess that LDAP would be the same.