Captive portal issue with user concurrency

docwho76

I have a pfSense CARP cluster of two machines with 3 WAN interfaces in a failover group, no loadbalancing, running FreeRADIUS and the Captive Portal.

What I am trying to achieve is the following result. If a user logs into the CP via their wifi interface on their laptop, and then later connects to the network via their laptops ethernet jack I want the username & password they used on the wifi to NOT WORK for the second login attempt via the ethernet.

Basically I want 1 login to 1 MAC address.

Reading around the forums it looked like the only way to do this was to use FreeRADIUS and set a users "multiple connections" value to 1. I have done this on my test setup and now what happens is, a user can login the first time via whatever interface they are using. But if they then try to login via a different connection (i.e a different MAC address) the CP login page doesnt give an error and the /var/log/radius.log file shows the login as successfully authenticated, but the user cant get out to the Internet now.

So is there some better way to do 1 login to 1 MAC address that doesnt have this false positive result on the second login or do I just need to configure my CP differently? Here is the CP config:

 <captiveportal><interface>lan</interface>
	 <maxproc><timeout><idletimeout><auth_method>radius</auth_method>
	 <reauthenticateacct><httpsname><bwdefaultdn><bwdefaultup><certificate><private-key><redirurl><radiusip>10.0.0.1</radiusip>
	 <radiusip2><radiusport>1892</radiusport>
	 <radiusport2><radiusacctport><radiuskey>lan</radiuskey>
	 <radiuskey2><radiusvendor>default</radiusvendor>
	 <page><htmltext>PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFsLy9FTiI+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ+Cjx0aXRsZT5Mb2NhdGlvbkNvbm5lY3QgQ1AgUmVkaXJlY3Q8L3RpdGxlPgo8TUVUQSBIVFRQLUVRVUlWPSJSRUZSRVNIIiBDT05URU5UPSIxO1VSTD0vY2FwdGl2ZXBvcnRhbC1sY2xvZ2luLnBocCI+CjwvaGVhZD4KPGJvZHk+CkxvYWRpbmcuLi4KPC9ib2R5Pgo8L2h0bWw+</htmltext>
		<errtext>PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMDEgVHJhbnNpdGlvbmFsLy9FTiI+CjxodG1sIGxhbmc9ImVuIj4KPGhlYWQ+Cjx0aXRsZT5Mb2NhdGlvbkNvbm5lY3QgTG9naW4gRXJyb3I8L3RpdGxlPgo8L2hlYWQ+Cjxib2R5PgoiJFBPUlRBTF9NRVNTQUdFJCIKPC9ib2R5Pgo8L2h0bWw+</errtext></page> 
	 <allowedip><ip>10.0.0.3</ip>
		<descr>DNS forwarder</descr>

<dir>to</dir></allowedip> 
	 <allowedip><ip>4.2.2.1</ip>
		<descr>Root DNS server</descr>

<dir>to</dir></allowedip> 
	 <enable><noconcurrentlogins><logoutwin_enable></logoutwin_enable></noconcurrentlogins></enable></radiuskey2></radiusacctport></radiusport2></radiusip2></redirurl></private-key></certificate></bwdefaultup></bwdefaultdn></httpsname></reauthenticateacct></idletimeout></timeout></maxproc></captiveportal>

I've removed content elements from the code above for clarity's sake. Here are the relevant sections of the FreeRADIUS config as well:

	 <freeradius><config><username>dspisak</username>
			<password>XXXXXXXX</password>
			 <ip><multiconnet>1</multiconnet>
			 <expiration><sessiontime><onlinetime><description><vlanid><additionaloptions></additionaloptions></vlanid></description></onlinetime></sessiontime></expiration></ip></config></freeradius> 
	 <freeradiussettings><config><interface>lan</interface>
			<port>1892</port>
			<radiuslogging>yes</radiuslogging>
			<radiuslogbadpass>yes</radiuslogbadpass>
			<radiusloggoodpass>yes</radiusloggoodpass></config></freeradiussettings> 
	 <freeradiusclients><config><client>10.0.0.1</client>
			<shortname>left-pfsense</shortname>
			<sharedsecret>lan</sharedsecret>
			<description>Left pfSense system</description></config> 
		 <config><client>10.0.0.3</client>
			<shortname>lan-vip</shortname>
			<sharedsecret>lan</sharedsecret>
			<description>CARP VIP on LAN</description></config></freeradiusclients>

Any help would be greatly appreciated.

cybrsrfr

I have done this with both the internal database and with radius connecting to a freeradius server.

Most of the Attributes that can be setup in FreeRadius the current Captive Portal will simply ignore. Many of them are yet to be implemented in the Captive Portal.

Here is a method that should work.

Services -> Captive Portal -> First Tab
Look for 'Maximum concurrent connections' and set to 1. When captive portal sees a user that is already logged in it will log concurrent login in the logs under Status -> System Logs -> Portal Auth will remove the old mac address and add the new one. You should then see the new MAC address under Status -> Captive Portal.