Captive portal & squid in a non-transparent mode: CP bypassed



  • Hi there.

    I'm running pfSense 2.0.1 (x32) with Captive Portal, squid & squidguard in a non-transparent environment, so I set proxy address & port (3128) in every computer.
    Doing so, CP is bypassed so the user login screen is never displayed and the user has full access (where squidguard rules apply).
    CP user login screen is displayed in the proxy is set in transparent mode, but therefore https traffic is not logged.

    Am I doing something wrong?

    Thank you very much in advance.
    Jesus



  • Well, it looks like I found an answer to my question digging into this forum.

    http://forum.pfsense.org/index.php/topic,40552.0.html

    Anyway, any help appreciated.
    Jesus



  • If you are on 2.0.1, you can try this patched file

    https://github.com/downloads/marcelloc/pfsense-packages/captiveportal_201_amd64.inc

    backup your /conf/inc/captiveportal.inc file on root dir for example and then copy the above file to /etc/inc/captiveportal.inc

    After replacing this file, apply captive portal and see if squid port(3128) is blocked until you login.



  • Thank you for your help.

    We are running x32 version of pfSense 2.0.1. Will this patch apply too?

    Regards,
    Jesus



  • As it's a php script, it should work but I will check it and feedback.

    Keep on mind that this file is a patch I did for testing, It's not an oficial patch yet. :)



  • I did some tests and this script doesn't seem to make any difference.
    I turned off Transparent proxy, started up CP after setting proxy:server on browsers. Clients surf freely.



  • Its configured to block port 3128.

    disable transparente proxy, check squid port, go to captive portal and apply settings.

    can you post after this the result of ipfw show command?

    A user from brazilian forum tested it and it's working.



  • Here is the output:
    –------------------
    65291    0      0 allow pfsync from any to any
    65292    0      0 allow carp from any to any
    65301  21    876 allow ip from any to any layer2 mac-type 0x0806
    65302    0      0 allow ip from any to any layer2 mac-type 0x888e
    65303    0      0 allow ip from any to any layer2 mac-type 0x88c7
    65304    0      0 allow ip from any to any layer2 mac-type 0x8863
    65305    0      0 allow ip from any to any layer2 mac-type 0x8864
    65306    0      0 allow ip from any to any layer2 mac-type 0x888e
    65307    1      99 deny ip from any to any layer2 not mac-type 0x0800
    65310 1329  160362 skipto 65314 ip from any to { 255.255.255.255 or 172.26.6.1 } dst-port 3128 in
    65310  75    5480 allow ip from any to { 255.255.255.255 or 172.26.6.1 } in
    65311 2221 2275614 skipto 65314 ip from { 255.255.255.255 or 172.26.6.1 } 3128 to any out
    65311  68    9104 allow ip from { 255.255.255.255 or 172.26.6.1 } to any out
    65312    0      0 allow icmp from { 255.255.255.255 or 172.26.6.1 } to any out icmptypes 0
    65313    0      0 allow icmp from any to { 255.255.255.255 or 172.26.6.1 } in icmptypes 8
    65314 3746 1173979 allow ip from table(3) to any in
    65315 3492 2177509 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 1329  160362 allow ip from any to table(7) in
    65319 2221 2275614 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 allow ip from table(1) to any in
    65323    0      0 allow 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



  • 65310 1329  160362 skipto 65314 ip from any to { 255.255.255.255 or 172.26.6.1 } dst-port 3128 in
    

    Well, the rule is there and It's counter shows 1329 hits.

    But the forward rule has no match.

    Can you check captive portal configuration to see if there is no exception That Allow this traffic?



  • I have attached two screenshots.

    The changes you made does work when browser is set to autodetect Proxy settings.
    It doesn't work when proxy:port is set manually.






  • @jmarquez:

    I have attached two screenshots.

    The changes you made does work when browser is set to autodetect Proxy settings.
    It doesn't work when proxy:port is set manually.

    When you say it does't works means no access or full access.

    On the tested setup, we left a site without proxy in browser configuration, for example www.google.com.
    (no proxy for:localhost, 127.0.0.1, www.google.com, 192.168.1.1(pfsense ip))

    And configured www.google.com to be the start page.

    This way when browser opens, www.google.com is called and captive portal shows its auth page.

    att,
    Marcello Coutinho



  • Thank you for your help Marcello. I really appreciate it.

    By "it doesn't work" I mean that users get full access without CP auth screen showing up.

    The problem (only) arises whenever proxy:port is set (as shown in itDoesNOTwork.png).
    I mean that the browser and/or squid bypasses CP auth screen, so users get full access to the internet (where squidguard rules apply).

    Regards,
    Jesus.



  • I'll do more tests here and feedback when possible.


Log in to reply