Captive Portal is still not working.
-
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 ?.
-
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 -
The rule issue should be fixed.
Also only port 80 and 443(if enabled) will be forwarded now. -
@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.
-
While this won't help short term, RFC 6585 (http://tools.ietf.org/html/rfc6585) introduced the HTTP 511 status code: Network Authentication Required.
-
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.
-
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.
-
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 anyAny suggestions?
-
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.
-
@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.
-
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.
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.
-
@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.
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.
