Captive Portal is still not working.

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.

dhatz

@cmb:

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.

Absolutely, it only makes sense if you've somehow first imported your own root CA cert into all the clients' certificate store. Given that, in the previous example the ZS CP will create the "correct" SSL cert on the fly, based on what the client asked for.

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

Perhaps you should hint at these private versions, or people will go look elsewhere …

Anyway, wrt the CP, probably the most useful feature (in a commercial context) would be PMS integration.