What is the best way to troubleshoot login issues?

Supermule

How are they handling cookies? Do they block or dont accept by default?

Its not in the security settings, but the handling of login parameters in the browser…

insurin

Hi Supermule

I am not sure what you mean. I will turn the security settings down the next time it happens.

I have setup a syslog server and I am now pumping the portalauthlogs out to that. I will have to wait until I get a user who cannot login before I can monitor their login process.

lynx

now I got same problem..

. so I followed one tutorial and setup networkpolicy in my AD and make it a radius server…

when I try to log in to the portal.. its not redirecting to google which I setup in redirectUrl....

it keeps on asking me to log-in... :(

insurin

Lynx

I would first off check the logs on your NPS/Radius server to see what's happening. If there is a radius issue, you should get an error at the logon screen saying 'no radius response' (something along those lines).

insurin

Out of curiosity, what does the following log indicate?

logportalauth[43261]: TIMEOUT: username, mac, ip address

Timeout is what I curious about. I am seeing a lot of it in my logs.

Gertjan

@insurin:

Out of curiosity, what does the following log indicate?
logportalauth[43261]: TIMEOUT: username, mac, ip address
Timeout is what I curious about. I am seeing a lot of it in my logs.

/etc/inc/captiveportal.inc says in the function captiveportal_prune_old():
TIMEOUT happens when the idle time out arrives, hard time, session time out, voucher, radius etc.

The fonction captiveportal_prune_old() is run every minute by a cron task.
It removes the portal connections that where established, and reached the end.

Gertjan

More on TIMEOUT:
Its what happens after user logged in.
(So there is a valid session, portal firewall rules are activated to let the user out, hard time out and soft time time are counted, etc - the user should be able to surf the net)

Jun 9 08:27:05 	logportalauth[20106]: CONCURRENT LOGIN - REUSING OLD SESSION: 104, 24:xx:64:21:2e:a1, 192.168.2.149
Jun 9 08:27:05 	logportalauth[20106]: LOGIN: 104, 24:xx:64:21:2e:a1, 192.168.2.149
Jun 9 08:26:01 	logportalauth[55814]: LOGIN: 104, 24:xx:64:21:2e:a1, 192.168.2.149
Jun 9 05:54:21 	logportalauth[20106]: LOGIN: 211, a4:xx:d2:48:20:f3, 192.168.2.151
Jun 9 05:44:16 	logportalauth[14947]: TIMEOUT: 211, a4:xx:d2:48:20:f3, 192.168.2.151
Jun 9 00:44:15 	logportalauth[55814]: LOGIN: 211, a4:xx:d2:48:20:f3, 192.168.2.151
Jun 8 20:47:52 	logportalauth[49541]: TIMEOUT: 201, 90:xx:7c:8a:3f:8c, 192.168.2.158
Jun 8 19:33:22 	logportalauth[55814]: CONCURRENT LOGIN - REUSING OLD SESSION: 201, 90:xx:7c:8a:3f:8c, 192.168.2.158
Jun 8 19:33:22 	logportalauth[55814]: LOGIN: 201, 90:xx:7c:8a:3f:8c, 192.168.2.158
Jun 8 19:32:59 	logportalauth[55814]: CONCURRENT LOGIN - REUSING OLD SESSION: 201, 90:xx:7c:8a:3f:8c, 192.168.2.158
Jun 8 19:32:59 	logportalauth[55814]: LOGIN: 201, 90:xx:7c:8a:3f:8c, 192.168.2.158
Jun 8 19:25:16 	logportalauth[20106]: LOGIN: 201, 90:xx:7c:8a:3f:8c, 192.168.2.158
Jun 8 13:27:54 	logportalauth[60793]: TIMEOUT: 211, a4:xx:d2:48:20:f3, 192.168.2.151
Jun 8 10:59:14 	logportalauth[93838]: TIMEOUT: 104, 24:xx:64:21:2e:a1, 192.168.2.149
Jun 8 10:50:11 	logportalauth[98826]: TIMEOUT: 206, 3c:xx:f4:44:b8:58, 192.168.2.156
Jun 8 10:47:10 	logportalauth[10666]: TIMEOUT: 206, b0:xx:94:99:a1:da, 192.168.2.155
Jun 8 10:35:07 	logportalauth[17403]: TIMEOUT: 212, 3c:xx:72:14:6e:6f, 192.168.2.152
Jun 8 10:29:34 	logportalauth[20106]: LOGIN: 211, a4:xx:d2:48:20:f3, 192.168.2.151
Jun 8 09:45:53 	logportalauth[45180]: TIMEOUT: 212, 18:xx:a2:6a:fc:14, 192.168.2.157
Jun 8 09:45:53 	logportalauth[45180]: TIMEOUT: 205, 30:xx:c9:cf:7c:1e, 192.168.2.127
Jun 8 09:06:42 	logportalauth[4923]: TIMEOUT: 211, a4:xx:d2:48:20:f3, 192.168.2.151
Jun 8 08:51:38 	logportalauth[55487]: TIMEOUT: 102, 00:xx:5b:c3:6c:91, 192.168.2.150
Jun 8 08:50:38 	logportalauth[38730]: TIMEOUT: 205, 1c:xx:94:9c:3e:9a, 192.168.2.130

Every minut,
(Do a
ps ax | grep 'prune'
to see the task)
hard time out and idle time is checked. for every logged in user.
You are using radius, so other checks might happen.
When the time is up, firewall rules are removed, the user session is destroyed, the user is cut from the net, and a TIMEOUT message is being logged.

insurin

update

I had the same issue yesterday. I had a user trying to login through the CP portal. After entering their credentials, the screen just refreshes and asks them to login again but Radius is authenticating them. I watched the portauthlog and nothing new appeared and the user is not shown on the Captive Portal Status page.

I next looked at the IP address that the user had picked up. Let's say they had picked up 192.168.1.40. I searched the CP status page and saw another user logged in with that IP address. As soon as I deleted that session for 192.168.1.40 I can then get this user to login without any issues.

I need to look into more detail then next time it happens.

I have idle and hard timeout set to 6 hours. I also have my dhcp lease set to 6 hours.

Gertjan

@insurin:

I next looked at the IP address that the user had picked up. Let's say they had picked up 192.168.1.40. I searched the CP status page and saw another user logged in with that IP address. As soon as I deleted that session for 192.168.1.40 I can then get this user to login without any issues.

Analyse this situation.
A DHCP server that starts out dealing an IP that's actively already used by another user: Its shouldn't do that, big troubles will arrive.

@insurin:

I have idle and hard timeout set to 6 hours. I also have my dhcp lease set to 6 hours.

Idle time : 30 minutes
=> because: if the users doesn't do anything on the network, have it removed.
Hard time out : 360 minutes (6 houres)
=> Always good to have a hard time out.
DHCP lease: a little bit more then the hard time out: 400 minutes or 24000 secondes.
=> Lease time is expressed in secondes and the DHCP server page.

insurin

Hi Gertan

I will try those settings out.

Just to confirm. My Windows DHCP server was not issuing the same IP address to 2 different clients. I think it was more to do with pfsense/captive portal already having a connection on that IP address with another user and when this new user tried to authenticate with the same IP address it caused CP to error. This may be fixed by the settings you have suggested so I will implement them now.

cheers

Gertjan

@insurin:

…..I think it was more to do with pfsense/captive portal already having a connection on that IP address with another user and when this new user tried to authenticate with the same IP address it caused CP to error.

I rephrase.
A user (with an IP obtained from your DHCP server) has a device with a MAC address.
He connects to the portal interface, a session is opened with its
IP
MAC
Start time
End time (the End time will be 'Start time' + 'hard time out')
Session-ID
Etc.

This user will NOT be redirected to the portal login web interface anymore.
This user should manually LOGOUT (using the popup, so the session will be portal will be destroyed) if he want to see the portal login web interface again.
His IP stays the same all this time.

If another user connects, it should NOT obtain the same IP (IP conflict ! - note that user CAN hard code the IP, you better ignore these users ;)).
This other user has of course another MAC ….

I cannot imagine how is could be possible that two users have the SAME IP ..... your DHCP will never allow that.
A unique user with its unique MAC will receive a unique IP.
This is how thing work in DHCP land :)