Captive Portal is still not working.

periko

I download:

built on Mon Dec 10 16:51:49 EST 2012

Setup captive portal, local users, freeradius2 but looks like we still have the problem that cp is not working, anyone on that interface can navigate without any issue, is not even showing the login screen.

I found this threads here from June with the same issue.

Any news about?

eri--

You need to provide more information about this.
Show CP config you have
ipfw_context -l
ipfw show
ipfw table all list
ipfw pipe show
ifconfig

periko

ipfw_context -l
Currently defined contextes and their members:
cp: vr0,

ipfw show
65291 0 0 allow pfsync from any to any
65292 0 0 allow carp from any to any
65301 0 0 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302 0 0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303 1734 858344 allow ip from any to any layer2
65307 0 0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310 0 0 allow ip from any to { 255.255.255.255 or 192.168.50.1 } in
65311 0 0 allow ip from { 255.255.255.255 or 192.168.50.1 } to any out
65312 0 0 allow icmp from { 255.255.255.255 or 192.168.50.1 } to any out icmptypes 0
65313 0 0 allow icmp from any to { 255.255.255.255 or 192.168.50.1 } in icmptypes 8
65314 0 0 allow ip from table(3) to any in
65315 0 0 allow ip from any to table(4) out
65316 0 0 pipe tablearg ip from table(5) to any in
65317 0 0 pipe tablearg ip from any to table(6) out
65318 0 0 allow ip from any to table(7) in
65319 0 0 allow ip from table(8) to any out
65320 0 0 pipe tablearg ip from any to table(9) in
65321 0 0 pipe tablearg ip from table(10) to any out
65322 0 0 pipe tablearg ip from table(1) to any in
65323 0 0 pipe tablearg ip from any to table(2) out
65531 0 0 fwd 127.0.0.1,8000 tcp from any to any in
65532 0 0 allow tcp from any to any out
65533 0 0 deny ip from any to any
65534 0 0 allow ip from any to any layer2
65535 0 0 allow ip from any to any

ifconfig
em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 00:11:0a:53:c9:10
inet6 fe80::211:aff:fe53:c910%em0 prefixlen 64 scopeid 0x1
inet WAN-IP netmask 0xffffff80 broadcast 255.255.255.255
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
em1: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic>ether 00:11:0a:53:c9:11
inet6 fe80::211:aff:fe53:c911%em1 prefixlen 64 scopeid 0x2
inet 172.16.1.1 netmask 0xffffff00 broadcast 172.16.1.255
nd6 options=1 <performnud>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
vr0: flags=108843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=82808 <vlan_mtu,wol_ucast,wol_magic,linkstate>ether 00:e0:c5:4e:36:60
inet 192.168.50.1 netmask 0xffffff00 broadcast 192.168.50.255
inet6 fe80::2e0:c5ff:fe4e:3660%vr0 prefixlen 64 scopeid 0x7
inet6 fe80::1:1%vr0 prefixlen 64 scopeid 0x7
nd6 options=1 <performnud>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
plip0: flags=8810 <pointopoint,simplex,multicast>metric 0 mtu 1500
enc0: flags=0<> metric 0 mtu 1536
pfsync0: flags=0<> metric 0 mtu 1460
syncpeer: 224.0.0.240 maxupd: 128 syncok: 1
lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
options=3 <rxcsum,txcsum>inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb
nd6 options=3 <performnud,accept_rtadv>pflog0: flags=100 <promisc>metric 0 mtu 33200
ipfw0: flags=8801 <up,simplex,multicast>metric 0 mtu 65536</up,simplex,multicast></promisc></performnud,accept_rtadv></rxcsum,txcsum></up,loopback,running,multicast></pointopoint,simplex,multicast></full-duplex></performnud></vlan_mtu,wol_ucast,wol_magic,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic></up,broadcast,running,simplex,multicast>

cp settings, I have try local users and freeradius, using the same settings as 2.0.1.

The other commands doesn;t show info, thanks!!!

MoSpock

CP does indeed not work.
It seems redirection is broken.

If i manualy enter the adres
http://<ip>:8000 or https://<ip>:8001 i get the CP page.</ip></ip>

periko

U must be right, because port 8000 is open at my box.
I will try your tip, thanks!!!

eri--

The issue is here


65303 1734 858344 allow ip from any to any layer2

Where do you get that from?
Any mac pasthrough rule or somesuch?

dhatz

@periko:

65322 0 0 pipe tablearg ip from table(1) to any in
65323 0 0 pipe tablearg ip from any to table(2) out
65531 0 0 fwd 127.0.0.1,8000 tcp from any to any in
65532 0 0 allow tcp from any to any out
65533 0 0 deny ip from any to any
65534 0 0 allow ip from any to any layer2
65535 0 0 allow ip from any to any

I wonder, is it really necessary to fwd all traffic to lighttpd listening at port 8000, since it can only respond to HTTP anyway ?

Last year I tested some changes to the CP ipfw rules:

[snip]
65318 0 0 allow ip from any to table(7) in
65319 0 0 allow ip from table(8) to any out
65320 0 0 pipe tablearg ip from any to table(9) in
65321 0 0 pipe tablearg ip from table(10) to any out
65322 583159 40179494 allow ip from table(1) to any in
65323 952054 1346348093 allow ip from any to table(2) out
65510 84 14142 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65511 77 42384 allow tcp from any to any out
65512 12 1796 reset tcp from any to any
65513 1014 54357 unreach port udp from any to any
65533 0 0 deny ip from any to any
65534 0 0 allow ip from any to any layer2
65535 0 0 allow ip from any to any

In another test I added a ipfw dynamic rule (… limit src-addr x) in an attempt to protect lighttpd listening on port 8000/8001 from intentional or unintentional abuse …

MoSpock

65291 0 0 allow pfsync from any to any
65292 0 0 allow carp from any to any
65301 9 342 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302 0 0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303 213 121201 allow ip from any to any layer2
65307 0 0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310 0 0 allow ip from any to { 255.255.255.255 or 192.168.128.1 } in
65311 0 0 allow ip from { 255.255.255.255 or 192.168.128.1 } to any out
65312 0 0 allow icmp from { 255.255.255.255 or 192.168.128.1 } to any out icmptypes 0
65313 0 0 allow icmp from any to { 255.255.255.255 or 192.168.128.1 } in icmptypes 8
65314 0 0 allow ip from table(3) to any in
65315 0 0 allow ip from any to table(4) out
65316 0 0 pipe tablearg ip from table(5) to any in
65317 0 0 pipe tablearg ip from any to table(6) out
65318 0 0 allow ip from any to table(7) in
65319 0 0 allow ip from table(8) to any out
65320 0 0 pipe tablearg ip from any to table(9) in
65321 0 0 pipe tablearg ip from table(10) to any out
65322 0 0 pipe tablearg ip from table(1) to any in
65323 0 0 pipe tablearg ip from any to table(2) out
65531 0 0 fwd 127.0.0.1,8000 tcp from any to any in
65532 0 0 allow tcp from any to any out
65533 0 0 deny ip from any to any
65534 0 0 allow ip from any to any layer2
65535 0 0 allow ip from any to any

65303 213 121201 allow ip from any to any layer2 -> is probaly te cause. But where does is come from?

I have no rules that allow mac adressen. Is that even possible?

freebee

Same problem here. The rule id is the same. Deleted and everything work again. No mac address rules (just download and upload limit). The captive is running in a virtual wireless interface. If you click in save, the rule 65303 back again to ipfw.

65291 0 0 allow pfsync from any to any
65292 0 0 allow carp from any to any
65301 0 0 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302 0 0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303 4310 1387588 allow ip from any to any layer2
65307 0 0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310 0 0 allow ip from any to { 255.255.255.255 or 10.7.7.1 } in
65311 0 0 allow ip from { 255.255.255.255 or 10.7.7.1 } to any out
65312 0 0 allow icmp from { 255.255.255.255 or 10.7.7.1 } to any out icmptypes 0
65313 0 0 allow icmp from any to { 255.255.255.255 or 10.7.7.1 } in icmptypes 8
65314 0 0 allow ip from table(3) to any in
65315 0 0 allow ip from any to table(4) out
65316 0 0 pipe tablearg ip from table(5) to any in
65317 0 0 pipe tablearg ip from any to table(6) out
65318 0 0 allow ip from any to table(7) in
65319 0 0 allow ip from table(8) to any out
65320 0 0 pipe tablearg ip from any to table(9) in
65321 0 0 pipe tablearg ip from table(10) to any out
65322 0 0 pipe tablearg ip from table(1) to any in
65323 0 0 pipe tablearg ip from any to table(2) out
65531 0 0 fwd 127.0.0.1,8000 tcp from any to any in
65532 0 0 allow tcp from any to any out
65533 0 0 deny ip from any to any
65534 0 0 allow ip from any to any layer2
65535 44 12487 allow ip from any to any

In a fast search i found this:
/etc/inc/captiveportal.inc: Line 527.
add 65303 set 1 pass layer2 mac-type pppoe_disc,pppoe_sess

This line was add in this change:
https://github.com/bsdperimeter/pfsense/commit/ee79fcda34ce65d9a9e99c26983659a5bc115b75

Possible fix ?.

freebee

Other thing is, the Allowed IP address and Allowed hostnames don't work.
I can't ping or navigate (or download images from) in domains registered in this areas.

Somebody else can confirm this ?.

periko

I setup freeradius2 with CP and once I follow the instructions from MoSpock I receive the error:


Fatal error: Class 'Auth_RADIUS_' not found in /usr/local/captiveportal/radius_authentication.inc line 104

eri--

The rule issue should be fixed.
Also only port 80 and 443(if enabled) will be forwarded now.

dhatz

@ermal:

and 443(if enabled) will be forwarded now.

Forwarding 443 to the CP (e.g. people trying to connect to facebook or gmail via https reaching lighttpd listening on e.g. 8001 instead) will just produce a "big scary warning" in practically all cases.

dhatz

While this won't help short term, RFC 6585 (http://tools.ietf.org/html/rfc6585) introduced the HTTP 511 status code: Network Authentication Required.

bardelot

@dhatz:

While this won't help short term, RFC 6585 (http://tools.ietf.org/html/rfc6585) introduced the HTTP 511 status code: Network Authentication Required.

They could have made clearer how they expect the browser to handle the certificate error, with section 7.4 stating:

Also, note that captive portals using this status code on a Secure
Socket Layer (SSL) or Transport Layer Security (TLS) connection
(commonly, port 443) will generate a certificate error on the client.

If the browser still shows a certificate mismatch to the user I don't really see a huge improvement and even less any browser vendor caring to implement that rfc.

cmb

It's not much of an improvement to redirect HTTPS since it's impossible to provide a cert that doesn't throw up a big ugly warning. But most commercial CP implementations do redirect HTTPS to the portal and generate a cert warning, so I guess that's the route we'll probably end up taking… Though we probably need to go back and change this so it only redirects HTTPS if you have HTTPS enabled on the portal, as is I believe it'll redirect HTTPS to the HTTP port if you're not using HTTPS, which will just result in a failed connection. Maybe better than sitting there and timing out I guess.. not sure, there isn't a great answer, and with more and more sites defaulting to HTTPS (Google being a big one that a significant number of people have set as their home page), it's becoming more important.

MoSpock

With the last snapshot: 2.1-BETA1 (i386) built on Sat Dec 15 00:36:37 EST 2012 FreeBSD 8.3-RELEASE-p5
the client cannot connect to the internet when Captive Portal is enabled. So tht's better.
However the client is not redirected to the captivge portal.

ipfw show output:
65291 0 0 allow pfsync from any to any
65292 0 0 allow carp from any to any
65301 9 360 allow ip from any to any layer2 mac-type 0x0806,0x8035
65302 0 0 allow ip from any to any layer2 mac-type 0x888e,0x88c7
65303 0 0 allow ip from any to any layer2 mac-type 0x8863,0x8864
65307 0 0 deny ip from any to any layer2 not mac-type 0x0800,0x86dd
65310 33 3919 allow ip from any to { 255.255.255.255 or 192.168.128.1 } in
65311 56 38702 allow ip from { 255.255.255.255 or 192.168.128.1 } to any out
65312 0 0 allow icmp from { 255.255.255.255 or 192.168.128.1 } to any out icmptypes 0
65313 0 0 allow icmp from any to { 255.255.255.255 or 192.168.128.1 } in icmptypes 8
65314 0 0 allow ip from table(3) to any in
65315 0 0 allow ip from any to table(4) out
65316 0 0 pipe tablearg ip from table(5) to any in
65317 0 0 pipe tablearg ip from any to table(6) out
65318 0 0 allow ip from any to table(7) in
65319 0 0 allow ip from table(8) to any out
65320 0 0 pipe tablearg ip from any to table(9) in
65321 0 0 pipe tablearg ip from table(10) to any out
65322 0 0 pipe tablearg ip from table(1) to any in
65323 0 0 pipe tablearg ip from any to table(2) out
65532 60 6680 fwd 127.0.0.1,8000 tcp from any to any dst-port 80 in
65533 6 684 allow tcp from any to any out
65534 188 43179 deny ip from any to any
65535 4 336 allow ip from any to any

Any suggestions?

bardelot

I made pull requests that will fix a bug related to the https redirection rule and a second one with the php pfSense module.

You can wait for them being included in a next snapshot or apply the patches yourself.

dhatz

@cmb:

It's not much of an improvement to redirect HTTPS since it's impossible to provide a cert that doesn't throw up a big ugly warning. But most commercial CP implementations do redirect HTTPS to the portal and generate a cert warning, so I guess that's the route we'll probably end up taking…

Which commercial CP implementations do that ? Because I've checked quite a few, and haven't seen that yet, except in the context I've mentioned (MiTM). Please also note that in recent years the popular browsers produce even more strongly worded warnings about the SSL certificate CN mismatch.

One scenario I've encountered is when the CP uses a wildcard SSL cert and extracts the CN on the fly and uses it as the hostname to redirect to e.g. http://www.zeroshell.org/forum/viewtopic.php?t=703

There are several features of commercial CP implementations that could be added to enhance pfsense, such as auto-adding OCSP URLs of the CP's SSL cert to a whitelist ("walled garden") so that clients running newer OSes (e.g. MacOS X 10.7.x +) work correctly.

cmb

Name of the vendor escapes me at the moment, but it's one of the biggest ones you find in many chain hotels. I travel a lot and always try CPs to see if they intercept HTTPS. The big vendors almost all do.

Using wildcard certs doesn't help with the main problem, you can't get a wildcard cert on any domain. eg the interception of say https://google.com can't not produce a cert error.

@dhatz:

There are several features of commercial CP implementations that could be added to enhance pfsense, such as auto-adding OCSP URLs of the CP's SSL cert to a whitelist ("walled garden")

which we already have in private versions, amongst many other features. May or may not get open sourced at some point.