Anyone else running a WiSP and using pfSense?
-
Is it strange that the other ipfw commands that you mentioned before didn't do anything when i ran them?
Well, perhaps I wasn't clear enough
/tmp/ipfw.cp.rules is a text-file that contains the ipfw configuration, so you just check its contents (using vi, more etc)
ipfw table all list was to check if you had any entries in ipfw tables. Since it came empty, it means you don't (which is to be expected, since you only use MAC passthrough).So, as I wrote above, you need to check whether any MAC-addresses you want blocked are still in the 'ipfw show' list. And you need to check that you haven't disabled MAC filtering.
-
What about MAC addr 08:10:74:75:98:9e which seems to appear in two rule pairs?
00186 0 0 pipe 20187 ip from any to any MAC 08:10:74:75:98:9e any
00187 458 24248 pipe 20186 ip from any to any MAC any 08:10:74:75:98:9e
[…]
00198 0 0 pipe 20199 ip from any to any MAC 08:10:74:75:98:9e any
00199 0 0 pipe 20198 ip from any to any MAC any 08:10:74:75:98:9eWhat is the result of
fgrep 08:10:74:75:98:9e /cf/conf/config.xml -
luke -or anyone else who is regularly adding/removing MACs from CP's MAC-passthrough page-, could you please check your router's ipfw show output for:
-
MACs that appear in more than one rule pair (as shown in the excerpt above)
-
multiple lines with the same rule number (as shown in issue #1958 )
TIA
-
-
Just a quick reply to let you know i am traveling at the moment and will check this out and post back as soon as i am back home
-
If you're using MAC passthrough and deleting entries, it will delete the one you specify but it also deletes part of others that will break their access. ticket here: http://redmine.pfsense.org/issues/1976
work around, hit Save under Status>Captive Portal to correctly reload.
-
dhatz, could you tell me how i do this? ther isalot more data than i can see on screen when i run ipfw show.. can u pipe it through more to see a screen at a time?
I hope we can sort this out, i am getting to a point where this is causing problems. My network is open replying on the Captive Portal catching people who connect. Currently, ever new connection is getting online without being authenticated via CP.. they are somehow just passing by. This is only happening on the outdoor clients connecting through my outdoor AP (which is on LAN interface) but prople connecting through my office AP (connected on OPT1 interface) arr getting stopped by the CP login page.
We are currently adding more and more clients, but i am having to hide my SSID currently to try and stop unwanted peopl eusing the network.. what i really need is that SSID broadcasting cause it is a good way for us to get more clients when people see it and phone us up.
-
Any more ideas here?
-
I suspect CP on LAN might be a fairly uncommon configuration and consequently not well tested.
You do have CP enabled on BOTH LAN and OPT1? If so, can you move the offending AP to (say) OPT2.
-
It was all working until i did the upgrade to 2.0-RELEASE.
I dont have an Opt2 interface. Only WAN, LAN and OPT1. I will try swapping the AP from LAN to OPT1 and see if it works, just to see if the issue is the AP or the Captive Portal.. cause as i said before, on OPT1 currently i have just a small indoor WAP, and the Captive portal works.. but for my outdoor Ruckus AP it isn't anymore.
-
It was all working until i did the upgrade to 2.0-RELEASE.
Upgrades can sometimes change the configuration file. Do you have CP enabled on LAN?
-
Yes, it is as it was before the upgrade. I have CP enabled on both LAN and OPT1
-
CP works fine on LAN and is extensively used and tested there. Probably want to gitsync to RELENG_2_0, or wait for 2.0.1 that will be coming this week, if you're using a lot of MAC passthroughs and editing them frequently since we fixed an issue there.
-
And i am guessing not go the upgrade route? do a clean install? I dont mind if i have to do that, just alot more work and i have the problem that i want to keep all cache and lightsquid logs..
-
luke, if you're in a hurry, you could also manually apply the bugfix, it's this one:
https://github.com/bsdperimeter/pfsense/commit/e3db5627224a0293f74e0d032a9b230f98f85952
I haven't noticed any issues with MAC passthrough since.
-
dhatz thanks for that.. a hurry i definately am in. Ill give this a try and see what happens and report back. Thanks
just to be clear, i am just to add this line:
+ $ruleno = captiveportal_get_next_ipfw_ruleno(2000, 49899, true);(do i add the "+" at the start also?)
Or am is supposed to delete these lines also:
- if ($enBwup && $enBwdown)
945
- $ruleno = captiveportal_get_next_ipfw_ruleno(2000, 49899, true);
946
- else
947
- $ruleno = captiveportal_get_next_ipfw_ruleno(2000, 49899, false); -
You must delete the lines marked with "-" and add the line marked with "+"
Or you can do as indicated by cmb
Probably want to gitsync to RELENG_2_0
edit:
you have attached the "captiveportal.inc.png" from a pfsense 2.0.1 amd 64
remove the .png and upload to /etc/inc/
-
Ok, so here is my problem that i have absolutely no idea how to fix. I just applied that patch thanks to dhatz, i dont know what that will fix but we will see. I have rebooted since applying.
So i have 1 client. His MAC is not even in the Captive Portal MAC passthrough list, he is on the DHCP Leases list and also on the ARP Table. Lightsquid logs shows his usage. I currently see him onlne and see the Lightsquid logs for this user changing so i assume he is browsing, however.. i just did a ipfw show and his MAC is not in there at all…
What is going on here??
-
Your clients need to have an IP address before they can talk with the captive portal. Hence they could well have ARP entries and DHCP leases and still not be able to communicate with the web.
I don't know about Lightsquid - perhaps it captures a web access BEFORE it gets to Captive Portal.
-
Your clients need to have an IP address before they can talk with the captive portal. Hence they could well have ARP entries and DHCP leases and still not be able to communicate with the web.
I don't know about Lightsquid - perhaps it captures a web access BEFORE it gets to Captive Portal.
Wallabybob i think you are missing the point i have been making here.. this is the issue, clients ARE getting on the web, and passed teh Captive Portal but i have no idea why? They should be getting stopped at the Captive Portal logon screen but no longer are. This particular MAC isnt showing in the ipfw show but i know for certain that the client is browsing the web no problems..
-
This particular MAC isnt showing in the ipfw show but i know for certain that the client is browsing the web no problems..
Please run a packet capture on that particular client's IP address and interface. The capture may give some clues as to how they are bypassing CP.
Wallabybob i think you are missing the point i have been making here.. this is the issue, clients ARE getting on the web, and passed teh Captive Portal but i have no idea why?
Sorry, when you said @luke240778:
So i have 1 client. His MAC is not even in the Captive Portal MAC passthrough list, he is on the DHCP Leases list and also on the ARP Table. Lightsquid logs shows his usage. I currently see him onlne and see the Lightsquid logs for this user changing so i assume he is browsing, however.. i just did a ipfw show and his MAC is not in there at all…
I thought you were offering "having a DHCP lease and an ARP entry" as part of the evidence of being able to bypass CP.
Now that I have thought about things a bit more, I wonder if the issue is that the client is getting into SQUID rather than CP and the squid accesses on behalf of that client are able to bypass CP because they are sourced "locally". I don't know enough about squid, CP and their interactions to be able to suggest how you might explore that theory.
