No internet access when user restarts device after connected to CP

[ssattannae]

Hi,
I couldn't find any related topics on this issue so I apologize if this has been discussed before.

I'm current facing a problem where if users connect to my pfsense router, then they have no problem accessing the internet. If they restart their devices then there will be no internet access, but on the router it still shows they are logged in. I'm thinking the issue might be they need to be disconnected so the current sessions can be but I'm not sure. Any help will be appreciated, thanks!

[Gertjan]

Hi,

You should know what happened when users are 'logged in'.

By default, a "portal" is nothing more or less then a firewall that blocks any traffic from any devices.
The "portal" trick is that incoming connections to "any IP - port 80" and or "any IP port 443" are redirected to the internal web server. This web server shows a "login page". Posting this page back (+ entering credentials) will open up the firewall for the connected device : the MAC address and IP address are placed in a table in the firewall. Any traffic afterwards, from this device, will pas through the firewall.

When you restart a device, it's MAC address shouldn't change.
The device will ask again, during startup, an IP address. The DHCP server, running on pfSense, remembers the device very well - it recognizes the MAC in its tables, and give the same IP.
Your device should pass through - no need to reconnect - the device is still connected from a point of view of pfSense.

So, the question is : what happens on your network ?
Does the device gets the same IP after restart ? Normally, it should, DHCP works like that. This is easy to check.

So, tell us what is so special on your portal network.

[ssattannae]

Thanks for the response!

I used ifconfig to check the test device IP after after it restarts and it's the same as before restarting.

I don't think it's there's anything special about the portal network, thought I'm new to pfsense so here's more information about the portal in case I missed any:

1. the portal uses RADMAC authentication method
2. portal will re-auth users every minute
3. popup window disabled
4. there are some custom code in the portal index.php to fit business logic. The code only handles cases when radius returns no and does not affect anywhere else.
5. disabling the portal will allow user to get online which is expected, but this should mean the problem lies with my portal.

I am going to change authentication method and see if anything improves, though I don't think radius server is the issue.

[Gertjan]

See https://docs.netgate.com/pfsense/en/latest/captiveportal/captive-portal-troubleshooting.html

The console firewall commands will list you the IP's and MAC's of your devices.

You stated that the device, when restarted, obtained the same IP.
The MAC is of course the same.

The portal (pfSense) can't really see or know if your devices restarted, it might as well go out of sight, a Wifi connection became bad or the cable was ripped of.
All it (pfSense) knows is that device asked again for an IP after it restarted - and because his lease hasn't expired yet, it will hand over the same IP as before.
So all conditions are met.

I don't know how RADMAC auth works : is Radius pinging or arping the device to check if its reachable ? If so, if it wasn't there anymore, will RADMAC 'logout' the device. In that case, the portal status page of pfSEnse should reflect that = the device was removed - and thus the related firewall table were removed.
Is that the case ?

Also : it's a know fact : it starts with the main index.php file and the underlying /etc/inc/captiveportal.inc file : it's a beautiful mess .... but it works after lighting years of testing hours.
Ok to change the scripts (the 'code') , but be ready to see unknown side effects.

On my portal, using FreeRadius - and every 5 minutes it re-authenticate, I can shut down my iPhone, start it up again, and it is still connected (no authentication needed) and my 'login" is still listed in the captive portal status page.

Btw :

@ssattannae said in No internet access when user restarts device after connected to CP:

I'm current facing a problem

and

@ssattannae said in No internet access when user restarts device after connected to CP:

there are some custom code in the portal index.php to fit business logic.

means you're working on a system with only one expert : you.

[ssattannae]

Thanks for the input @Gertjan ! After checking out the link you gave me I was able to find out that the user will disappear from the _auth_down and _auth_up IPFW tables, I'm certain this is the cause for the connection loss. I will post an update if I manage to solve this and hopefully help others in similar situation.

[Gertjan]

@ssattannae said in No internet access when user restarts device after connected to CP:

will disappear from the _auth_down and _auth_up IPFW

If they are removed from the xxxxx_auth_down and xxxxx_auth_down tables, then "pfSense" is instructed by the exterior "auth" method to do so.
FreeRadius that is.

[ssattannae]

Sorry for the late update. So basically my problem is really similar to this post https://forum.netgate.com/topic/137824/pfsense-no-internet-when-it-is-said-you-are-connected/13 and this post https://forum.netgate.com/topic/136262/clients-can-t-reconnect-after-pfsense-reboot. From What I've seen there's no perfect solution yet, so I set the idle timeout to 10 minutes and added a check before radius accounting packet is sent. Basically I am checking if octet input and output is 0 when some amount of time has passed (less than the idle timeout) then chances are the user is no longer in the ipfw table and safe to disconnect. I probably violated some networking convention but there doesn't seem to be a perfect solution yet. Hopefully this will help someone in a similar situation.

[free4]

@ssattannae one question : did you try to apply the patch?

if you are facing the issue mentioned above...it may help

[ssattannae]

@free4 oh my god thanks for reminding me. I went to check my patch url again and I realized I missed the .diff part at the end, initial testing indicates the patch seems to work. Will update after doing some more testing.

Okay everything seems to be in order, thanks again @free4 @Gertjan for your inputs. Though it turned out to be a dummy mistake on my end haha

[free4]

@ssattannae you are welcome

if after further testing you still think that the patch is really fixing your problem...then don't hesitate to make a thumbs up on https://github.com/pfsense/pfsense/pull/4042 and/or make a small comment "friendly bump, this pull request resolve a very impactful problem..."

The patch and pull request are ready since a while (2.4.4-p2)...the current stable release is 2.4.4-p3 and the pull request is not merged yet...