Captive Portal (authentication page not opening in browser when enter website)
-
Hi,
I want to setup captive portal for wifi authentication, so all users authenticate first through radius server and then access internet.
I installed Pfsense in hyperv . Added an extra lan interface (OPT1) and set static ip (10.10.10.10) and enabled DHCP server on it. I
also setup LINKSYS AP in same subnet with static IP(10.10.10.15) with gateway of Pfsense IP .
Now all users are getting ip from dhcp server . But when they open browser and enter website , it do not show captive portal authentication page. The user have to manually enter http://10.10.10.10:8000 to open captive authentication page.
How can i automate it so user dont have to enter this link (http://10.10.10.10:8000) and it automatically open when user enters website.
Regards,
-
Are they able to resolve DNS names?
Are they trying to open an HTTPS site on initial browse? (That is a problem with all captive portals, try an http site.)
-
DNS forwarder is enabled on interface , And yes the clients can resolve DNS names. I confimed it from cmd prompt.
The user is opening HTTP site . But still the authentication page is not opening.
If i manually enter http://x.x.x.x:8000 , then it works. Otherwise it shows "This page can't be displayed."
-
I'm unclear. Are they able to browse the web or do their connections just hang?
If your linksys AP is not an AP but is a router, as soon as one person behind the router is authenticated, everyone behind the router is authenticated. Is the DHCP IP they're getting from the linksys or pfSense?
If none of this is the case, what do the following commands show?
ipfw_context -l
ipfw -x your_portal_name list
Your portal name will be listed by the previous command along with which interfaces it's listening on.
-
The DHCP Server is running on PfSense. The AP is open.
When user opens any website in browser. The browser does not redirect to authenticate page.
If user manually enter pfSense portal address ( http://x.x.x.x:8000) , then it works.
[2.1.4-RELEASE][admin@pfsense.localdomain]/root(1): ipfw_context -l
Currently defined contextes and their members:
eduroam: de2,[2.1.4-RELEASE][admin@pfsense.localdomain]/root(2): ipfw -x your_portal_name list
65291 allow pfsync from any to any
65292 allow carp from any to any
65301 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303 allow ip from any to any layer2 mac-type 0x8863,0x8864
65307 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310 allow ip from any to { 255.255.255.255 or 10.87.192.27 } in
65311 allow ip from { 255.255.255.255 or 10.87.192.27 } to any out
65312 allow icmp from { 255.255.255.255 or 10.87.192.27 } to any out icmptypes 0
65313 allow icmp from any to { 255.255.255.255 or 10.87.192.27 } in icmptypes 8
65314 pipe tablearg ip from table(3) to any in
65315 pipe tablearg ip from any to table(4) in
65316 pipe tablearg ip from table(3) to any out
65317 pipe tablearg ip from any to table(4) out
65318 pipe tablearg ip from table(1) to any in
65319 pipe tablearg ip from any to table(2) out
65532 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65533 allow tcp from any to any out
65534 deny ip from any to any
65535 allow ip from any to any -
The DHCP Server is running on PfSense. The AP is open.
Verify the clients are actually getting an IP from pfSense and not the dlink.
When user opens any website in browser. The browser does not redirect to authenticate page.
What happens instead?
What happens if you put a hardwire client on the same segment as the AP?
If user manually enter pfSense portal address ( http://x.x.x.x:8000) , then it works.
[2.1.4-RELEASE][admin@pfsense.localdomain]/root(1): ipfw_context -l
Currently defined contextes and their members:
eduroam: de2,[2.1.4-RELEASE][admin@pfsense.localdomain]/root(2): ipfw -x your_portal_name list
65291 allow pfsync from any to any
65292 allow carp from any to any
65301 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303 allow ip from any to any layer2 mac-type 0x8863,0x8864
65307 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310 allow ip from any to { 255.255.255.255 or 10.87.192.27 } in
65311 allow ip from { 255.255.255.255 or 10.87.192.27 } to any out
65312 allow icmp from { 255.255.255.255 or 10.87.192.27 } to any out icmptypes 0
65313 allow icmp from any to { 255.255.255.255 or 10.87.192.27 } in icmptypes 8
65314 pipe tablearg ip from table(3) to any in
65315 pipe tablearg ip from any to table(4) in
65316 pipe tablearg ip from table(3) to any out
65317 pipe tablearg ip from any to table(4) out
65318 pipe tablearg ip from table(1) to any in
65319 pipe tablearg ip from any to table(2) out
65532 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65533 allow tcp from any to any out
65534 deny ip from any to any
65535 allow ip from any to anyAll that looks good. See that line 65532? That means if the user isn't already through because they are already authenticated they get forwarded to the portal. There really is no getting around it.
-
Okay I turn off the extra NIC (OPT1). And enabled captive portal on LAN interface and now it is working and opening properly.
I still dont know what is the issue on NIC ( OPT1 ) . May be firewall is stopping. But i have created any any allow rule .
Regards,
-
Be happy to look at the rule if you'd post it.
Glad it's working.
You did change the captive portal interface to OPT1 right?
-
Hi! Wakan
Try adding the the OPT 1 int IP address and also the DNS IP into the list of Allowed IP's under CP.
Regards
Harsh
-
I'm using pfsense. 2.1.5. I've tested it with packets squid and squid 3.
My scenario is real and has a twist: my WAN is 192.168.0.0 and 10.1.0.0 is my LAN. So my WAN has LAN address.
When I activate the Captive portal it does not appear when trying to open a website. But I tested in another scenario where the WAN has address WAN and there worked perfectly.
Does anyone know how I could make it work using WAN 192.168.0.0 with transparent proxy?
Obs:
DNS: 8.8.8.8 and 8.8.4.4
WAN 192.168.0.1
LAN: 10.1.0.1 -
Captive portal is not compatible with squid (at least transparent) on the same node. You could have an upstream caching/filtering node with the portal node behind it though.