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

marcelloc

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.

jmarquez

Thank you for your help.

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

Regards,
Jesus

marcelloc

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. :)

jmarquez

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.

marcelloc

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.

jmarquez

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

marcelloc

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?

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.

itDoesWork.png_thumb

itDoesNOTWork.png_thumb

marcelloc

@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

jmarquez

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.

marcelloc

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