Captive portal & squid in a non-transparent mode: CP bypassed
-
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 inWell, 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.
-
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.
