Captiv portal and vouchers integration with ssid on wlc 9800

Gertjan

@Jozy said in Captiv portal and vouchers integration with ssid on wlc 9800:

The device I'm using for this is android, with Ip address x.x103.48/24 and gateway 103.1 given from DHCP server configured on WIN server, actually I get it when try to connect to SSID which redirects me.
I'm using internal DNS x.x.112.10 and gateway x.x.112.1

That's ... strange.
( The gateway and DNS is outside of the network your portal clients get, so not reachable )
.
When your obtained a lease, but not logged in yet, your device can't reach anything outside of the 'portal network'.
Btw : hiding RFC1918 is meaningless. For example, your " x.x103.48" is RFC1918, right ?

Example : My captive portal interface uses :

And this is my Portal (OPT) DHCPv4 server :

@Jozy said in Captiv portal and vouchers integration with ssid on wlc 9800:

Yes, I know if we remove lines form /etc/inc/captiveportal.inc will remove user and password functions.

That's not the way of doing things.
You should make your own html login (and error) html page, and uploading it into pfSense here :

Jozy

@Gertjan hm
lets see something

10.223.110.155 is pfSense ip address while 192.168.15.1 is opt which I bind to CaptivPortal

My concerns is following: if I want to reach 192.168.15.1 which is Captiv Portal , how should I do it since this network is on virtual interface of my VMware.
Does it mean I have to configure new vlan and configure it through the network or I have to than configure rules on pfSense?

Should this network range being used by clients connecting to SSID even if I have already configred DHCp for that SSID on Win side? hm
Regarding HTML, I would like first focus on solving this.

Best regards,
Jozy

Jozy

@Gertjan @johnpoz Hi

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 ESTABLISHED

When 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

johnpoz

@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.

Jozy

@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 :)

johnpoz

@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.

Jozy

@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

johnpoz

@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.

Gertjan

@johnpoz

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.conf

In 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 /24

And 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.

johnpoz

@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.