Captive portal in 2.0 Release not working?
-
Ive had my captive portal working with no issues until i have recently upgraded to 2.0-release.
I have wireless clients connecting with their MAC in the Mac pass through. When they dont pay i take them out of there and they are presented with the login page and they know then to pay.. Not now.. even the people i have cut are still up and surfing, even after a reboot. Now today i have even had an antenna that connected and was surfing without even putting it in the MAC list.. how can i fix this? i am afradi that everyone is going to get on and take my bandwidth..
-
What authentication method have you enabled?
-
Authenticating to my external Radius server. We in the office who login with a username and password are working.. those external people who have an antenna to connect, and are not in the Passthrough MAC list should get the captive portal login page.. but aren't… they are just passing by it and straight on to the web..
-
Maybe try a clean install to 2.0. Call me paranoid but with such big changes in versions I tend to prefer to do a clean install. It takes a bit longer but I take a second box and configure everything to match the original. Perform a few tests and switch out the old one for final testing. if no go then I just switch the cables back and continue troubleshooting. If all is good then ;D ;D ;D
-
How can i do this and still keep my squid cache? that is very important for me as my bandwidth is not huge..
-
Sorry, I don't understand the phrase:
@luke240778:those external people who have an antenna to connect,
Perhaps it is hiding a crucial detail.
-
simple search on the web gives this….
In the last episode (Dec 29), Imran Imtiaz said:
i am running squid on my freebsd 5.4 now i want to shift on freebsd
6.0 is there a way that I can import my old cached object on the new
system cause i have a huge cache which i don't wanna lose.Just copy your cache directory to the new server and make sure the
new server's squid.conf cache settings match the old one.Maybe sftp into the pfsense the old pfsense. Copy and sftp into new one and replace....
I do not use squid so not sure where it is stored....
-
Sorry, I don't understand the phrase:
@luke240778:those external people who have an antenna to connect,
Perhaps it is hiding a crucial detail.
Sorry, yeah that makes no sense.. what i meant to say is: In the office we connect through WAP, and the captive portal works. If you dont login, the net doesnt work. On the outside i have an antenna serving my WiSP.. Those clients connect to my antenna with their CPE's.. and some of these are passing straight through to the net.. Not getting the captive portal login at all..
-
OK, so some of these persons bypassing the captive portal come through an external AP? Does their access come with a MAC address of the AP (which is one of the bypass MAC addresses) rather than the actual originating MAC address. Or, are these APs routers rather than bridges?
-
As suggested, you need to check the setup of your APs.
Anyway, using a captive portal for authentication usually isn't the best way to go for a WISP, because it is susceptible to MAC addr spoofing. You should consider switching to PPPoE.
-
OK, so some of these persons bypassing the captive portal come through an external AP? Does their access come with a MAC address of the AP (which is one of the bypass MAC addresses) rather than the actual originating MAC address. Or, are these APs routers rather than bridges?
All of the people bypassing the Captive portal are connecting through my Outdoor AP (Ruckus ZoneFlex 2741).. The ZF2741 is basically just a bridge. All of these peoples MAC's show in my DHCP list on pfsense, but for some reason, this all worked perfectly until around 2 weeks ago. Their MAC's show up on the Ruckus as being connected, i see them in DHCP leases but they are not on my MAC pass through list in captive portal, and from Swuid logs i see that they are browsing.
2 Weeks ago 2 things happened.. I updated from 2.0-RC3 to 2.0-RELEASE, and i also updated the Ruckus AP to new firmware.
My office, we connect through a normal indoor AP, in Bridge mode, connected to OPT1 on pfsense, for this, captive portal works as it should..
-
As suggested, you need to check the setup of your APs.
Anyway, using a captive portal for authentication usually isn't the best way to go for a WISP, because it is susceptible to MAC addr spoofing. You should consider switching to PPPoE.
The AP has been working fine as is for months, the setup of these are simple.. my setup basically is as folows:
Pfsense with 3 x NIC.. WAN, LAN and OPT1
LAN IP: 192.168.10.1
OPT1 IP: 192.168.5.1Ruckus ZF2741 outdoor IP settings are just simply (connected to a switch on LAN interface):
IP : 192.168.10.50
GATEWAY: 192.168.10.1Office AP:
192.168.5.254
GATEWAY: 192.168.5.1PPPoE is actually what i have been reading up on and want to do.. but i have around 80 clients and from what i can tell, their antennas (CPE) dont support PPPoE…
-
All of the people bypassing the Captive portal are connecting through my Outdoor AP (Ruckus ZoneFlex 2741).. The ZF2741 is basically just a bridge. All of these peoples MAC's show in my DHCP list on pfsense,
Which DHCP list on pfSense?
Have you verified that the source MAC address in traffic from users unexpectedly bypassing the captive portal is NOT the MAC address of the AP. (I'm not familiar with the ZF 2741 and I have read reports that some APs forward traffic with the MAC address of the AP rather than the MAC address of the client.)
-
All of the people bypassing the Captive portal are connecting through my Outdoor AP (Ruckus ZoneFlex 2741).. The ZF2741 is basically just a bridge. All of these peoples MAC's show in my DHCP list on pfsense,
Which DHCP list on pfSense?
Have you verified that the source MAC address in traffic from users unexpectedly bypassing the captive portal is NOT the MAC address of the AP. (I'm not familiar with the ZF 2741 and I have read reports that some APs forward traffic with the MAC address of the AP rather than the MAC address of the client.)
The DHCP Leases menu.
The SOurce MAC of the users that i am seeing bypassing the CP are the correct MAC of their CPE's, and not the AP. All currently connected clients, which i see in DHCP leases ad browsing are all the correct MAC of their CPE's.
I strangely, today am seeing 1 MAC, in the DHCP leases, also in the squid logs as browsing and downloading, with an IP in the LAN range.. so from the Outdoor AP.. buts its not showing up in the AP as a connected client at all (all other CPE's show up in the " connected clients" list on the AP.
-
I'm experiencing the same probleme with 2.0 release.
Pfsense doesn't add an pass-trough Mac permission to all Mac adresses that authenticate successfully on the captive portal. It seems just to add the pass-trough Mac permission absolutely randomly - sometimes it adds a permission - sometimes not.
The Option "Enable Pass-through MAC automatic additions" is always enabled.
I've tested several snapshots of the 2.0 Version and they definately don't have this problem.
I'm using PFSense NAND 4g on a Alix Board.
-
So there is obviously some bugs still in the 2.0-RELEASE? What can we do to sort this issue? If using the Captive portal to stop unwanted guests on our networks then this is really bad
-
So there is obviously some bugs still in the 2.0-RELEASE? What can we do to sort this issue? If using the Captive portal to stop unwanted guests on our networks then this is really bad
This is definetly a bug. A pretty bad one if you use pfsense in a business enviroment.
-
So there is obviously some bugs still in the 2.0-RELEASE? What can we do to sort this issue? If using the Captive portal to stop unwanted guests on our networks then this is really bad
This is definetly a bug. A pretty bad one if you use pfsense in a business enviroment.
Yeah.. which i do.. it is my captive portal for my WiSP.. Is there anyone out there who may know how to fix this?
It is strange, cause i havent changed my AP.. as in how it works, just did a firmware upgrade. Captive portal i have running on my LAN (WiSP users) and my OPT1 (Office).. is working as it should for Office, but not for WiSP.. Helppppp!!
-
You might find it useful to check the output of
ipfw show
ipfw table all list -
Lets hope that this bug will be fixed with the next update to make the captive portal usable again.
-
Captive portal works fine in 2.0 release.
The one issue here that has details sounds like the clients are coming from one AP's MAC rather than the CPE. The DHCP leases showing the correct MAC has no association to what MAC actually comes from the clients (check the ARP table for that).
-
@cmb:
Captive portal works fine in 2.0 release.
The one issue here that has details sounds like the clients are coming from one AP's MAC rather than the CPE. The DHCP leases showing the correct MAC has no association to what MAC actually comes from the clients (check the ARP table for that).
Hey sorry, not really understanding this.. my AP's i don't have in the Captive Portal MAC passthrough list… they are ust basically super bridges.
Am i misunderstanding?
-
Hey sorry, not really understanding this.. my AP's i don't have in the Captive Portal MAC passthrough list… they are ust basically super bridges.
They may be configured as such but that doesn't mean they're acting as such. There have been multiple reports on here of people's bridged wireless gear rewriting the source MAC on all traffic to the MAC of the AP, even though the firewall gets their DHCP requests coming from their real MAC. Checking Diag>ARP will show whether or not that's happening, what's shown there is the source MAC that's actually coming through.
-
hi
i have same probolem, to solve this just dont use the pass through mac, let them go through the captive portal.
there is even more serious problem, if they put the gatway IP in their proxy which i discovered by luck, there is no way to stop them from using your internet for free, even if you change squid port, it can be easly discovred with nmap.
hadi57
-
@cmb:
They may be configured as such but that doesn't mean they're acting as such. There have been multiple reports on here of people's bridged wireless gear rewriting the source MAC on all traffic to the MAC of the AP, even though the firewall gets their DHCP requests coming from their real MAC. Checking Diag>ARP will show whether or not that's happening, what's shown there is the source MAC that's actually coming through.
I'm using a couple of Linksys WRT54GS AP's, running the Talisman firmware with some ebtables for "client isolation".
When switching to another, more recent DD-WRT firmware version with the same ebtables setup, I saw that the MAC addresses of my clients became: the MAC op the AP ??? >:(
Because my AP's CAN communicate freely with the net to time sync etc, dis was NO good.
I threw out the inter-AP-client-isolation from my AP's.Btw: this is not really a pfSense issue.
there is even more serious problem, if they put the gatway IP in their proxy which i discovered by luck, there is no way to stop them from using your internet for free, even if you change squid port, it can be easly discovred with nmap.
Can you detail this a bit more ?
I have a Opt1 (192.168.2.0/24 - with Captive portal, a DHCP server) running for my clients.
My LAN is 192.168.1.0/24.
The Opt1 interface has the firewall rules that do not permit to touch anything but the Net.
You say that I would be able to toy with the IP settings of a client PC (Wifi or wire), so it can pass right though the Captive Portal (ipfw) firewall …
What about explaining how to do it ?
Do I need to install squid on pfSEnse (which I haven't, I don't think I need squid) so clients could take 'advantage' of that ? -
i am using squid in transparent mode, because that box have only 4mb and 45 concurrent users sometimes, so clients who are updating windoze, antivirus etc. will not eat the bandwidth. i am not saying the connection i perfect this way, but clients can still chatt, browse facebook. i tried once configuring my browser to use the gateway in the proxy setting, and i was shocked to access the internet without even passing to the captive portal, also one of my clients had his access point using dhcp, "i dont remember the detail, it is posted here long ago, so my client was able to use the internet for free and his complaint to me was that internet is slow only.
-
Well, I lost you while reading "… that box have only 4mb and ...".
Are you aware that pfSense can only run with 128 Mbytes of RAM, or more ?When you are using APs on a Captive Portal interface, best thing to do is:
Captive Portal IP: x.x.x.1
AP1: x.x.x.1
AP2: x.x.x.2
.... etc
APy: x.x.x.y
DHCP server range on Cative Portal Interface: x.x.x.y+1 - x.x.x.254
(or: give AP's an IP that's outside the Captive Portal DHCP IP mask)
This means that AP's should not have an IP that clients can obtain. Clients that starts to toy with a fixed IP, the same as an AP will gain a "MAC conflict" on the network.The AP's should be put in bridged mode, which means that pfSense's Captive Portal SEES the MAC of the clients.
This setup still has possibilities for forging: hi-jacking the IP and MAC of an authenticated client will gain access for you.
It will also create network conflicts ...Note that my AP's do NOT allow any x.x.x.a to x.x.x.b communication, except where the destination MAC is the MAC of the Captive Portal interface card. This is done with some 'ebtables firewall rules' in each AP.
All this means that without hard-core hacking (Wifi sniffing, etc) you can NOT fall throughout the Captive Portal access. It is programmed to block all, and lists exceptions for those who are authenticated. -
4 mb is my bandwidth, but i have others with 10, 16 and 20mb bandwidth, waiting for fiber optic to be available any where i have a box, ram on all boxes is 4 gig, using 64 amd version of pfsense, all of them have 64 intell 2 or 4 cpus, they are all doing fine with no issues.
-
Ideally use different VLANs to segregate traffic:
One VLAN to manage the the APs
Another VLAN to carry client traffic. -
@cmb:
Hey sorry, not really understanding this.. my AP's i don't have in the Captive Portal MAC passthrough list… they are ust basically super bridges.
They may be configured as such but that doesn't mean they're acting as such. There have been multiple reports on here of people's bridged wireless gear rewriting the source MAC on all traffic to the MAC of the AP, even though the firewall gets their DHCP requests coming from their real MAC. Checking Diag>ARP will show whether or not that's happening, what's shown there is the source MAC that's actually coming through.
Umm. still beyond my understanding here. But looking at the ARP Table as you mentioned, it all looks right to me.. i see all correct CPE MAC's and only see the AP mac for the correct IP that is the AP.. Am i following?
-
hi
i have same probolem, to solve this just dont use the pass through mac, let them go through the captive portal.
there is even more serious problem, if they put the gatway IP in their proxy which i discovered by luck, there is no way to stop them from using your internet for free, even if you change squid port, it can be easly discovred with nmap.
hadi57
But that is what i am saying all along is my problem. I have been putting all MAC's in the Passthrough list for clients, as at install they were getting the Captive Portal login, so i added them to the Passthrough MAC.. but lately, all new installs are just bypassing CP completely and straight onto the web.. they are not yet in the MAC passthrough list, and they bypass the CP somehow
-
Well, I lost you while reading "… that box have only 4mb and ...".
Are you aware that pfSense can only run with 128 Mbytes of RAM, or more ?When you are using APs on a Captive Portal interface, best thing to do is:
Captive Portal IP: x.x.x.1
AP1: x.x.x.1
AP2: x.x.x.2
.... etc
APy: x.x.x.y
DHCP server range on Cative Portal Interface: x.x.x.y+1 - x.x.x.254
(or: give AP's an IP that's outside the Captive Portal DHCP IP mask)
This means that AP's should not have an IP that clients can obtain. Clients that starts to toy with a fixed IP, the same as an AP will gain a "MAC conflict" on the network.Sorry you are saying to have the AP1 the same IP as the CP IP? (x.x.x.1)
-
Is there a known bug?
I use vouchers which should expire, but authenticated users aren't disconnected or redirected again to login page after expiration time. They can keep on surfing and are listed in "Status: Captive portal: Vouchers –> active users", but the voucher is deleted in 'active vouchers'. I can even manually disconnect them in 'active users' page but no effect. I have to disable and enable CP to end sessions.
Any hint what went wrong? I don't use pass-through-mac, but it is behaving like this feature.
-
-
What pfSense version ?
It is 2.0-RELEASE (amd64)
When the issue arrives, use these commands:
ipfw list
ipfw table all listThis does just show, not fix anything. Right?
My test vouchers are only 5 minutes valid. Is this too short? Curiously yesterday when just one AP was configured with guest ssid, it worked.
Well, I'll check the tables when issue occures next time.
-
Well, I lost you while reading "… that box have only 4mb and ...".
Are you aware that pfSense can only run with 128 Mbytes of RAM, or more ?When you are using APs on a Captive Portal interface, best thing to do is:
Captive Portal IP: x.x.x.1
AP1: x.x.x.1
AP2: x.x.x.2
.... etc
APy: x.x.x.y
DHCP server range on Cative Portal Interface: x.x.x.y+1 - x.x.x.254
(or: give AP's an IP that's outside the Captive Portal DHCP IP mask)
This means that AP's should not have an IP that clients can obtain. Clients that starts to toy with a fixed IP, the same as an AP will gain a "MAC conflict" on the network.Sorry you are saying to have the AP1 the same IP as the CP IP? (x.x.x.1)
Gertjan can you clarify please?
-
Sorry you are saying to have the AP1 the same IP as the CP IP? (x.x.x.1)
Captive Portal IP: x.x.x.1
AP1: x.x.x.2
AP2: x.x.x.3
etc.Sorry, my fault.
AP1 can't have the same IP as the Captive portal IP interface ….. -
Sorry you are saying to have the AP1 the same IP as the CP IP? (x.x.x.1)
Captive Portal IP: x.x.x.1
AP1: x.x.x.2
AP2: x.x.x.3
etc.Sorry, my fault.
AP1 can't have the same IP as the Captive portal IP interface …..Ok yes, thats basically what i have..
CP IP: 192.168.10.1
AP1: 192.168.10.50
AP2: 192.168.10.51 -
Ok, so there is definately some bug in Captive Portal on 2.0. I am wondering if its best i start a new thread regarding this? And see if we ca all get it solved?
I have basically 2 exact same NIC's, LAN and OPT1. Both setup exactly the same, just differente IP's obviously.
Captive Portal enabled on both interfaces,on the LAN and connection goes straight passed the CP login screen, tried various AP's to make sure it wasnt one of them not working. The exact same setup on the OPT1 interface works perfectly.
I have tried by only activating CP on 1 at a time but get the same results. This must be a bug…
-
Can you post your config here with private information cleared to verify it?