Captive Portal is still not working.



  • 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?



  • 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



  • 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!!!



  • 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>



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



  • 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?



  • @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 …



  • 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?



  • 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 ?.



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



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



  • 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 any

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

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



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


Locked