Captiv portal and vouchers integration with ssid on wlc 9800
-
I have following situation
[2.7.2-RELEASE][admin@pfSense.home.arpa]/root: netstat -anl
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 96 10.223.110.155.22 10.223.100.28.54426 ESTABLISHED
tcp4 0 0 10.223.100.180.8002 10.223.100.28.54421 TIME_WAIT
tcp6 0 0 *.8003 . LISTEN
tcp4 0 0 *.8003 . LISTEN
tcp6 0 0 *.8002 . LISTEN
tcp4 0 0 *.8002 . LISTEN
tcp4 0 0 10.223.100.180.22 10.223.100.77.53762 ESTABLISHEDWhen telnetting to ports 80,443,8002,8003 everything works fine but not working when try to open on browser?
Seems there is some problem on Nginx, you know what it could be?Best regards,
Jozy -
Well yeah that not going to work...
https captive portals can be problematic - cuz your browser isn't going to trust the cert, and where you got sent isn't going to match the name the client is trying to go to, etc.
But in your case you tried to use plain old http but went to a https port.
Are you still trying to redirect in wlc? I showed you what happens when a phone tries to detect if there is a captive portal, it doesn't use https.
-
@johnpoz Im trying open in on PC over browser locally not over SSID configured on WLC. First i think I should have it running then can go to the second step and try to open it over SSID.
Is possible there is some bug?
If you can send we link to download proper version, since its possible that I have downloaded it from the wrong site :) -
@Jozy proper version of what? Open the captive portal in your browser from where.. There is redirection that happens as well.. Not sure you can just the captive portal without the redirection
[24.03-RELEASE][admin@sg4860.home.arpa]/root: cat /tmp/rules.debug | grep cpzoneid table <cpzoneid_2_cpips> { 192.168.200.1} ether pass on { igb3.10 } tag "cpzoneid_2_rdr" ether anchor "cpzoneid_2_auth/*" on { igb3.10 } ether anchor "cpzoneid_2_passthrumac/*" on { igb3.10 } ether anchor "cpzoneid_2_allowedhosts/*" on { igb3.10 } rdr on igb3.10 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.200.1 port 8002 pass in quick on igb3.10 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13001 keep state(sloppy) block in quick on igb3.10 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13003 [24.03-RELEASE][admin@sg4860.home.arpa]/root:
And there is some etherules as well that are going to happen.
If your on the network you have the captive portal on and you try and hit something on port 80, ie normal http you should be redirected to the captive portal.. I really don't feel like changing my network around to show some pictures of something that is so basic..
When I turn it on my guest network, its kicking my work laptop off the work vpn.. If I get a chance do some stuff so I can play with it without disrupting my normal flow. Could prob fire up another ssid and connect to that with my main pcs wifi card so not to mess with my normal access on my pc or my work laptop.
-
@johnpoz
Please can you check below output, U really dont know what the problem could be...
[2.7.2-RELEASE][admin@pfSense.home.arpa]/root: netstat -anl
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 96 10.223.110.155.22 10.223.100.28.51652 ESTABLISHED
tcp6 0 0 *.8002 . LISTEN[2.7.2-RELEASE][admin@pfSense.home.arpa]/root: cat /tmp/rules.debug | grep cpzoneid
table <cpzoneid_2_cpips> { 10.223.100.180}
ether pass on { vmx2 } tag "cpzoneid_2_rdr"
ether anchor "cpzoneid_2_auth/" on { vmx2 }
ether anchor "cpzoneid_2_passthrumac/" on { vmx2 }
ether anchor "cpzoneid_2_allowedhosts/*" on { vmx2 }
rdr on vmx2 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 10.223.100.180 port 8002
pass in quick on vmx2 proto tcp from any to <cpzoneid_2_cpips> port 8002 ridentifier 13001 keep state(sloppy)
block in quick on vmx2 from any to ! <cpzoneid_2_cpips> ! tagged cpzoneid_2_auth ridentifier 13003 -
@Jozy notice the port 8000, where is that coming from?
like I said I am not sure if you can just call up the IP on port 8002, without the redirection happening..
Here I fired up my wifi on my pc, no I can not just access http://192.168.6.8002, but if I try and go to some site that http, www.cnn.com in my example get redirect to the captive portal.
It currently isn't asking for voucher - because I currently don't have them turned on..
So put a pc on your whatever network your wanting to use for captive portal, and go to http://www.cnn.com and you should get redirected to the captive portal page.. here is sniff showing
I do a dns query for www.cnn.com, I then try and go to that IP.. 146.xx pfsense lets me think I am talking to that IP, but sends me a 302 saying hey go here 192.168.6.253:8002 with this specific url..
Which then presents me with the login..
This is really clicky clicky.. There is nothing really to do..vs trying to call up the portal page directly.. do what actually happens. I would suggest you duplicate the simple test I did.. I am showing you exactly what happens via the sniff I did.
-
Nice.
Your "cat /tmp/rules.debug | grep cpzoneid" shows how the portal works.This :
ether pass on { igb3.10 } tag "cpzoneid_2_rdr"
tags all the packets coming into your portal interface with "cpzoneid_2_rdr".
This is the magic :
rdr on igb3.10 inet proto tcp from any to ! <cpzoneid_2_cpips> port 80 tagged cpzoneid_2_rdr -> 192.168.200.1 port 8002
I read this as follows:
For the "tagged cpzoneid_2_rdr" tagged traffic do this :
Redirect (rdr) TCP traffic from anybody (all the devices on the portal network) with a destination that is not <cpzoneid_2_cpips> (= the pfSense captive portal interface IP or 192.168.200.1) to the portal interface (= the pfSense captive portal interface IP or 192.168.200.1) port 8002 (where 8002 is the http - not https - captive portal web server) as seen here :@Jozy said in [Captiv portal and vouchers integration with ssid on wlc 9800](/post/1196793): > tcp6 0 0 *.8003 . LISTEN > tcp4 0 0 *.8003 . LISTEN > tcp6 0 0 *.8002 . LISTEN > tcp4 0 0 *.8002 . LISTEN
where port 8002 is used for "http" and port 8003 is the "https" interface;
Btw : https is used when
is checked.Be ware, using https means you have to use a certificate that and portal user trusts ( !! ).
It might still work, with the classic browser warning that tells you you use a self signed certificate (and not trusted).Extra info :
See the nginx portal web server config file which is called something like :
/var/etc/nginx-cpzone1-CaptivePortal.confIn the "server" block, you see how redirecting is applied.
This works because :
When an Ethernet connection is created, first, the DHCP client does it's work.
When done, the network client has an IP, a gateway, a DNS and a network (mask).
If I take the example of @johnpoz this would be :
IP : 192.168.200.1
DNS 192.168.100.1 ( !! so pfSense is the 'DNS' for the assigned captive portal network clients)
Gateway : 192.168.200.1 ( !! )
Network : 255.255.255.0 or /24And now the real magic kicksz in : every device, actuall : every OS, as soon as a ethernet connection comues up, fires up a https request.
For an Apple device, this http (not / never https !) will be :
http://captive.apple.com/hotspot-detect.html
Click on it to see what is happens.
It should return a 6 letter "html page" showing just "Success".
If this is not the case, the presence of a captive portal is suspected.
The device will open up a web browser (or show a notification to the user somewhere) and it will visit the same link again http://captive.apple.com/hotspot-detect.html and time, as this is a browser request : a classic http = port 80 request, it will get redirected to the 192.168.200.1 IP - port 8002, and you'll be able see what happens.And what will show up ? Our login portal !
Another info page : See here : Status > System Logs > System GUI Service
where you can see the https requests from the captive portal web server. -
@Gertjan nice write up..
@Jozy you could always just have the wlc do the captive portal as well, the one reason I could see having pfsense doing it is if you also had wired devices on this same network that you wanted to have to use the captive portal as well.
Personally I have little use for captive portal.. For my guests that want to use my guest wifi network I just hand them a card with a qr code on it to get them on the network.. They would hate how long and complex the psk is to type in ;) hehehe
They really only make sense when you need to time limit someones access, or have them pay for access, or can not in anyway just let them know the psk, etc. There are plenty of use cases where it makes sense, but in a home or smb sort of setup not really.
-
@johnpoz said in Captiv portal and vouchers integration with ssid on wlc 9800:
I could see having pfsense doing it is if you also had wired devices on this same network that you wanted to have to use the captive portal as well.
Actually, wireless or wired devices, it's all the same.
After all, captive portal support is mostly handled by the connecting device, not the router/firewall, like pfSense. -
@Gertjan my point was if all he has was wireless devices he wanted on it he could just use the wlc.. Not sure how the wlc would work for wired device on the same vlan as the wifi?
-
@johnpoz
I really dont know what the exact issue is here.
Customer is looking for voucher on Guest SSID and it should be setup but now this is not working. :( -
@Jozy said in Captiv portal and vouchers integration with ssid on wlc 9800:
Customer is looking for voucher on Guest SSID
What do you man by that ? The customer doesn't have a voucher ? He lost it ?
Or do you mean : he doesn't know what to do with it ?
Or does the login screen not show up ?Normally, when installing a captive portal, set up one without any "users" or "vouchers", just this :
and make sure everything works first.
This 'everything' is actually a lot already.See also here for help : Troubleshooting Captive Portal
@Jozy said in Captiv portal and vouchers integration with ssid on wlc 9800:
but now this is not working.
It worked before ?