2.5.0 Captive portal logging issue

viktor_g

@sebbac Please create a detailed bugreport: https://docs.netgate.com/pfsense/en/latest/development/bug-reports.html

Gertjan

@SEBBAC : your using "RADIUS MAC Authentication"

It says :

... method will try to authenticate devices automatically with their MAC address without displaying any login page.

or : why is the captive portal shown .... as I can see the user click a button (the Ok button to proceed ?) : I see the POST log lines.

Their should not be a "displaying any login page."".
It should be : use the MAC of the device, and check that. All this happens without user interaction.

That said, I'm not using "RADIUS MAC Authentication" myself.

To see what happens :

stop the radius process.
Open a SSH or console, option 8.

radiusd -X

Now you see all the radius traffic with all the details.

When a devce cionnects to the network, does that generate lines on the screen ?
Read them carefully. They ALL matter (this is radius - don't worry, things don't get worse. Tame this beast and you can say you saw them all).

Btw : a 'good' SSH setup using Putty or others with can show color lines, which helps as Radius shows warnings in yellow and errors in red.

Bzck to :

@sebbac said in 2.5.0 Captive portal logging issue:

Clients (home network) were authenticated by MAC and/or (as fallback) Captive portal login with user/password and or Voucher code.

What probably happens : the MAC isn't recognized (known) and the auth system falls back to classic 'portal login'.

The message after correct credential input is still " MACHINE LOGIN: unauthenticated ...." which means (to me) that the radius MAC auth says "no go" but the credentials user and or voucher should be tested as it was a 'portal page login' - again : I saw the 'POST's.
Right ?

SEBBAC

@gertjan said in 2.5.0 Captive portal logging issue:

Their should not be a "displaying any login page."".
It should be : use the MAC of the device, and check that. All this happens without user interaction.

gerjan,

i appreciate your involvement but you did not understand my problem.

Client DO authenticate correctly with MAC. The fallback via portal login also DOES work correctly (for devices not authorized by MAC or when outside time allowed for given MAC).

The problem is WITH (default) portal web authentication page - and what i found out it is very likely with wrong redirection or some kind confusion between PFBOX IP addres and its domain name (beyond my understanding at this stage). I can successfully log in just by manual change in the HTML page displayed at client device (not the most convenient way though)

I will try to save confgin/reinstall from scratch to see if the problem persists... it could be just some bug with the upgrade process.

kzsk

@sebbac Please tell me where to make changes to the default portal authorization page? I have the same problems after upgrading to 2.5 (authorization with mac works perfectly, with login/pass no

A Former User

I am sorry to insist but I have 3 pfsense machine that are running 2.4.x version and the captive portal basic ( no radius or thing like that) is running smoothly e.i. as soon a client open chrome to get to the internet the portal logging page show-up and we can enter user/password or voucher code and gingo the client is on the net surfing smootly

Now with 2.5 the client open chrome and have to waitng 10 seconds for the portal logging page to display in an extra tab, what was not the case before, them we can enter user/password or voucher code and them wait an extra 5 second to get on the net.

To summarise from an end-user perspective:

Captive portal in pfsense 2.4.x a smooth experience
Captive portal in pjsense 2.5 what a boring stuff

What have changed in the code between the two version regarding captive portal I don't know but here are the facts.

If anyone as the same behaviour plese let me know.

free4

@pierrelyon
it could be caused by a variety of reasons, not necessarily related to pfSense : I got this issue myself because of DoH which got deployed on google chrome...

(EDIT : sorry I was wrong in my comment)

SEBBAC

@kzsk

For anyone for whom it might be useful.

My setup

pfSense box IP: 192.168.1.1
Hostname: pfsense
domain: dom

Default Captive Code (important code highlighted):

This does not work - It always returns "invalid credentials" and there is no sign in logs for any authentication try.

However if the code is modified in a way that pfSense.dom is replaced by IP ie:

Captive login works correctly.

pfSense.dom is correctly recognized as 192.168.1.1 IP address (alias setup in DNS Resolver on the pfsense box)

Any ideas?

Gertjan

There are ways to test "who waits for who and when".

The most easy one, and probably complicated on a hand-hold device: test name resolution or DNS. If DNS is flaky, the portal access goes down with it.
Everything goes down with a bad DNS.
And some devices are picky and stupid, like the owners, they plant a 8.8.8.8 everywhere. Which is in many way so wrong .....

Make the Resolver verbose - goto the Advanced settings page and make the log level 3 - and :

tail -f /var/log/resolver.log

Now you see real time DNS action.

The captive portal's web login page is only showed when the portal's web server that serves this page was asked for it :

tail -f /var/log/nginx.log | grep '192.168.2'

where '192.168.2' is your captive portals upper 3 network nibbles / digits.
As soon as you see a line like

Apr  8 20:50:23 pfsense nginx: 192.168.2.16 - - [08/Apr/2021:20:50:23 +0200] "GET /hotspot-detect.html HTTP/1.0" 302 0 "-" "CaptiveNetworkSupport-407.40.1 wispr"

you know the device throws out a 'http' request over port 80 to detect if it's behind a portal.
The portal(s firewall ipfw redirects this page request to the portal's webserver
This line follows :

Apr  8 20:50:23 pfsense nginx: 192.168.2.16 - - [08/Apr/2021:20:50:23 +0200] "GET /index.php?zone=cpzone1&redirurl=http%3A%2F%2Fcaptive.apple.com%2Fhotspot-detect.html HTTP/1.0" 200 1640 "-" "CaptiveNetworkSupport-407.40.1 wispr"

Here you can see that the request was redirected to "index.php" of the captive portal's web serer which produces the login page.
The initial "http://captive.apple.com/hotspot-detect.html" request is stored in the "redirurl" parameter, which will get used when authentication succeeds.
Which is rather stupid of course. Who wants to land on " http://captive.apple.com/hotspot-detect.html " after successful login ? (click and see for yourself).
Answer : No one.

IF "redirurl" is defined (it always is), this one :

has no effect ! the presence of an URL in "redirurl" is prioritized.
IMHO, a 'bug' non related to the subject of this thread.

@free4 : you know where to look, please tell me that I'm wrong.

Back to the subject : the test :
You can see in real time when your device is asking for a (login) page.
And when the captive portal's web server is sending the result, which should produce a page on your device's web browser.

All the rest is your device doing other things.

My experience : 2.5.0 isn't any different as 2.4.5 in captive portal 'auth' handling.

Side note : I know that Apple device (can) use others way of detecting a captive portal.
The method pfSense is using is the old fashioned way : a firewall intercepts port 80 TCP traffic and redirects to a local web server. That 'works'. As long as port 80 http requests are 'permitted' - and these will be abandoned soon : port 80 is condemn to die. Long live port 443 traffic, which use only TLS ..... and then redirection, MITM, all if that is impossible.
This is actually not a big issue, as captive portal is now defined in the RFCs.
It's dead easy and should work flawlessly : a DHCP option is present in the DHCP_OFFER protocol. It hands over the URL (to a json file ?) that the device should use (visit/get) to have the instructions to show the login page. Fast, easy and clean.
If this stupid world wide pandemic wasn't eating all my time I would have played with it by now.

Btw :

This is a part of the logs of some stupid Windows ( ?) device that does 'something' that doesn't look like it want to look for the presence of a captive portal :

Apr  8 20:31:51 pfsense nginx: 192.168.2.13 - - [08/Apr/2021:20:31:51 +0200] "POST /SpamResolverNG/SpamResolverNG.dll?DoNewRequest HTTP/1.0" 302 0 "-" "-"
Apr  8 20:31:54 pfsense nginx: 192.168.2.13 - - [08/Apr/2021:20:31:54 +0200] "GET /connecttest.txt HTTP/1.1" 302 5 "-" "Microsoft NCSI"
Apr  8 20:31:55 pfsense nginx: 192.168.2.13 - - [08/Apr/2021:20:31:55 +0200] "POST /SpamResolverNG/SpamResolverNG.dll?DoNewRequest HTTP/1.0" 302 0 "-" "-"
Apr  8 20:31:55 pfsense nginx: 192.168.2.13 - - [08/Apr/2021:20:31:55 +0200] "GET /connecttest.txt HTTP/1.1" 302 5 "-" "Microsoft NCSI"
Apr  8 20:31:56 pfsense nginx: 192.168.2.13 - - [08/Apr/2021:20:31:56 +0200] "POST /SpamResolverNG/SpamResolverNG.dll?DoNewRequest HTTP/1.0" 302 0 "-" "-"
Apr  8 20:31:59 pfsense nginx: 192.168.2.13 - - [08/Apr/2021:20:31:59 +0200] "\x17$\x10\x04\x00)\x9DE\x0B" 400 150 "-" "-"
Apr  8 20:32:00 pfsense nginx: 192.168.2.13 - - [08/Apr/2021:20:32:00 +0200] "POST /SpamResolverNG/SpamResolverNG.dll?DoNewRequest HTTP/1.0" 302 0 "-" "-"

It throws out a "http portal portal request", the "GET /connecttest.txt" but doesn't accept the logical following redirect from the captive portal's web server.
It hammers on with :
" POST /SpamResolverNG/SpamResolverNG.dll?DoNewRequest "

The captive portal's web server says something like "f*ck you - try again".
And round we go.

kzsk

Replacing $PORTAL_ACTION$ with a string with an ip address didn't help. In the logs of radius. log when trying to log in with a username/password, these are the entries

Fri Apr  9 08:40:26 2021 : Auth: (100984) Login incorrect (Failed retrieving values required to evaluate condition): [00-1c-25-36-8d-6b/raduissecret] (from client captiveportal port 2232 cli xx-xx-xx-xx-xx-xx) xx-xx-xx-xx-xx-xx

radiussecret - RADIUS MAC Secret
xx-xx-xx-xx-xx-xx - MAC of device

For some reason, instead of a login-password pair, the captive portal passes to radius a mac-Radius MAC Secret pair

SEBBAC

@kzsk

As a test - try creating Radius user with MAC addresses ( - separated) and see if that works.... It should.

kzsk

@sebbac it didn't work

seekerman

@kzsk i've same issue like you , the radius server send failed login error "Failed retrieving values required to evaluate condition): [xx-xx-xx-xx-xx-xx/<via Auth-Type = mschap>" , all configuration is correct but pfsense cannot retrive password from free radius.
please guide.

viktor_g

@seekerman Unable to reproduce, working fine for me:

May 15 09:27:53 pf41 logportalauth[346]: Zone: cpzone1 - ACCEPT: raduser1, de:5b:10:c5:bf:72, 192.168.88.7

Are you using "RADIUS MAC Authentication"?
How I can reproduce it step-by-step?

seekerman

@viktor_g said in 2.5.0 Captive portal logging issue:

Authentication

hi @viktor_g
tnx for reply
yeh i've use radius mac authentication base on documentation but i got this error in radius log.
please guide me for correct configuration
i've use capitve portal and radius server on pfsense and make a user in free radius with mac address of my client as username and secret in captive portal as password . but the radius server show me an error "RADIUS MAC Authentication Failed."
tnx

viktor_g

@seekerman said in 2.5.0 Captive portal logging issue:

@viktor_g said in 2.5.0 Captive portal logging issue:

Authentication

hi @viktor_g
tnx for reply
yeh i've use radius mac authentication base on documentation but i got this error in radius log.
please guide me for correct configuration
i've use capitve portal and radius server on pfsense and make a user in free radius with mac address of my client as username and secret in captive portal as password . but the radius server show me an error "RADIUS MAC Authentication Failed."
tnx

You need to enable Plain MAC Auth on the FreeRADIUS settings page and fill in CP RADIUS MAC Secret with any value.
Or create a RADIUS user with MAC username and password.

(0) Login OK: [de:5b:10:c5:bf:72/pass123] (from client local port 2002 cli de-5b-10-c5-bf-72) 
(0) Sent Access-Accept Id 185 from 127.0.0.1:1812 to 127.0.0.1:24100 length 0
(0) Finished request
Waking up in 4.9 seconds.

seekerman

@viktor_g said in 2.5.0 Captive portal logging issue:

(0) Login OK: [de:5b:10:c5:bf:72/pass123] (from client local port 2002 cli de-5b-10-c5-bf-72)

hi i'm already get right response from the free radius by command prompt just like you but in captive portal anything is wrong
please guide me.

seekerman

@seekerman user managment.JPG setting radius.JPG free radius.JPG

viktor_g

@seekerman Default Captive Portal MAC address syntax is "00:11:22:33:44:55", not "00-11-22-33-44-55"

also try to add MAC address on the FreeRADIUS / MACs page

wissesolutions

@seekerman found somewere in the forum that this is a bug on version 2.5 fixed in development version.. ill try and let you guys know