Captive portal do not block unauthorised connections anymore

gauravparashar24

Dear community members,
From couple of days we have been facing issue as captive portal do not.block unauthorised connections anymore. It is a strange problem. But we are not able to detect the issue. We have given vouchers to all our students and manually added MAC addresses of staff in mac section so to bypass captive portal page. Initially it worked fine for 1 month and then some days back it started allowing everyone whosoever connects to our wifi. Initially it used to redirect everyone to our captive portal page but one day it stopped showing the page and directly allows everyone to connect to internet.

My architecture is ISP ->pfsense->switch1->switch2->wifi access points
switch2-> switch3->Computers on wired LAN
We are using unmanaged switches.

I have checked the ip addresses pfsense is giving the same range as defined in pfsense I.e, 192.168.1.1-192.168.1.254. I tried restarting pfsense many times but nothing happened.

I reinstalled pfsense 2.3.2 on the new virtual box machine. As I turned on the captive portal It blocked all the IPs initially. Then I restored only captive portal from backup taken from earlier machine it again started allowing all the IPs. I think there is some bug in pfsense.

Gertjan

@gauravparashar24:

I think there is some bug in pfsense.

Is not compatible with:
@gauravparashar24:

I reinstalled pfsense 2.3.2 on the new virtual box machine. As I turned on the captive portal It blocked all the IPs initially. Then I restored only captive portal from backup taken from earlier machine it again started allowing all the IPs..

The problems arrive with YOUR setup.
Focus on that.

You can see for yourself what happens and why : use https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting

DaS

I run on the same problem updating an old 2.0.1 pfSense and could not solve it. The config/setup runs fine with 2.0.1 so i rolled backed and still use 2.0.1

Running 4 interfaces (PRODUCTION,CLIENTS_LAN,CLIENTS_WLAN,WAN), captive portal is enabled on both CLIENTS_ interfaces.
Routing 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 into PRODUCTION, default gateway via WAN.

Setting up cp works without adding the 3 routed subnets in allowed ip addresses. I think adding 192.168.0.0/16 is the problem, resulting all clients can connect to all internet websites without authentication / ping is also possible. Removing the rule it's working as supposed.

Maps

I have a issuse like this.
2 Wlan ( 2.4 an 5 Ghz ) and one V-lan brigdged.
No blocking from the portal. I use 2.3.1 p1.

With 3 interfaces and 3 subnets anr aktived the portal on Wlan 2 and Wlan 5 blocking will work well.

by the way , is there an easy way to check the system. A testool which checks the blocking without login ?

Gertjan

@Maps:

…..
by the way , is there an easy way to check the system. A testool which checks the blocking without login ?

That could not exist.
If a connection passes, there is no way to know 'why'.
If it doesn't, you just hit the 'wall' (firewall).

This is always transparent from a visitor's point of view.

Maps

"That could not exist." … last words.
I want to check my configution and the firewall. Something like a penetration test.
Because I saw the system don´t work well, with Vlan/wifi bridging.

Gertjan

@Maps:

"That could not exist." … last words.
I want to check my configution and the firewall. Something like a penetration test.

I thought you were talking about the captive portal (internal network).
You are here :
pfSense Forum » pfSense English Support » Captive Portal

Consider posting here :
pfSense Forum » pfSense English Support » Firewalling

pfSense, when installed, is as what FreeBSD advertises : one of the best.

@Maps:

Because I saw the system don´t work well, with Vlan/wifi bridging.

:o
Remember : a device like this (pfSense) is as good as …... the setup that has been done by the admin.
It's like a car : they can save lives, or kill people. Check with the one who's driving ;)

DaS

hi there again,

I played around with 2.3.2 in my lab and figured it out.

The old cp portal works flawless by adding the allowed ip "192.168.0.0/16", of course the pfSense interface / LAN Subnet my clients are using is in this range.
With 2.3.2 a client can access any ip without authentication as soon as the LAN subnet is added unter "allowed ip", which is used by the captive portal clients.

in my case:

setup all needed subnets manually, and add new one over time
add all subnets manually in this range except the one of the captive portal clients