Anyone else running a WiSP and using pfSense?

luke240778 · Nov 18, 2011, 12:21 AM

Any more ideas here?

wallabybob · Nov 18, 2011, 2:14 AM

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.

luke240778 · Nov 18, 2011, 5:17 AM

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.

wallabybob · Nov 18, 2011, 5:45 AM

@luke240778:

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?

luke240778 · Nov 18, 2011, 6:30 AM

Yes, it is as it was before the upgrade. I have CP enabled on both LAN and OPT1

cmb · Nov 20, 2011, 2:16 AM

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.

luke240778 · Nov 20, 2011, 6:20 AM

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

dhatz · Nov 20, 2011, 6:33 PM

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.

luke240778 · Nov 20, 2011, 8:25 PM

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);

ptt · Nov 20, 2011, 9:44 PM

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/

captiveportal.inc.png

luke240778 · Nov 20, 2011, 11:21 PM

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??

wallabybob · Nov 20, 2011, 11:56 PM

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.

luke240778 · Nov 21, 2011, 1:51 AM

@wallabybob:

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

wallabybob · Nov 21, 2011, 2:23 AM

@luke240778:

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.

@luke240778:

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.

luke240778 · Nov 21, 2011, 3:04 AM

@wallabybob:

@luke240778:

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.

@luke240778:

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.

IP address of the MAC i know is bypassing the CP is 192.168.10.241, here is a packet capture i just ran:

00:59:28.164510 IP 192.168.10.241.1534 > 204.236.234.74.80: tcp 588
00:59:28.164549 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 0
00:59:28.465596 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 313
00:59:28.465816 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 43
00:59:28.531317 IP 192.168.10.241.1534 > 204.236.234.74.80: tcp 0
00:59:36.671760 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 5
00:59:36.814082 IP 65.54.49.80.1863 > 192.168.10.241.2717: tcp 8
00:59:36.987721 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 0
01:00:18.851057 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 5
01:00:19.000373 IP 65.54.49.80.1863 > 192.168.10.241.2717: tcp 8
01:00:19.137851 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 0
01:00:50.510226 IP 192.168.10.241.1534 > 204.236.234.74.80: tcp 612
01:00:50.510265 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 0
01:00:50.972113 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 313
01:00:50.972267 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 43
01:00:51.028514 IP 192.168.10.241.1534 > 204.236.234.74.80: tcp 0
01:00:59.014654 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 5
01:00:59.157985 IP 65.54.49.80.1863 > 192.168.10.241.2717: tcp 8
01:00:59.289235 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 0
01:01:15.188511 IP 74.125.234.91.80 > 192.168.10.241.1739: tcp 0
01:01:15.208393 IP 192.168.10.241.1739 > 74.125.234.91.80: tcp 0
01:01:16.187616 IP 195.28.181.138.80 > 192.168.10.241.1740: tcp 0
01:01:16.199754 IP 192.168.10.241.1740 > 195.28.181.138.80: tcp 0
01:01:17.186638 IP 184.173.254.59.80 > 192.168.10.241.1746: tcp 0
01:01:17.195715 IP 192.168.10.241.1746 > 184.173.254.59.80: tcp 0
01:01:18.185736 IP 213.8.137.51.80 > 192.168.10.241.1748: tcp 0
01:01:18.196753 IP 192.168.10.241.1748 > 213.8.137.51.80: tcp 0
01:01:46.015915 IP 192.168.5.28 > 192.168.10.241: ICMP echo request, id 1024, seq 37241, length 24
01:01:46.017889 IP 192.168.5.28 > 192.168.10.241: ICMP echo request, id 1024, seq 42361, length 24
01:01:46.018875 IP 192.168.5.28 > 192.168.10.241: ICMP echo request, id 1024, seq 47481, length 24
01:01:46.101480 IP 192.168.10.241 > 192.168.5.28: ICMP echo reply, id 1024, seq 37241, length 24
01:01:46.142832 IP 192.168.10.241 > 192.168.5.28: ICMP echo reply, id 1024, seq 42361, length 24
01:01:46.144745 IP 192.168.10.241 > 192.168.5.28: ICMP echo reply, id 1024, seq 47481, length 24
01:01:47.158082 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 5
01:01:47.302091 IP 65.54.49.80.1863 > 192.168.10.241.2717: tcp 8
01:01:47.465471 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 0
01:01:59.586950 IP 192.168.10.241.1534 > 204.236.234.74.80: tcp 572
01:01:59.586991 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 0
01:01:59.967533 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 313
01:01:59.967812 IP 204.236.234.74.80 > 192.168.10.241.1534: tcp 43
01:01:59.978150 IP 192.168.10.241.1534 > 204.236.234.74.80: tcp 0
01:02:31.315672 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 5
01:02:31.462128 IP 65.54.49.80.1863 > 192.168.10.241.2717: tcp 8
01:02:31.614572 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 0
01:02:56.311476 IP 192.168.5.28.4193 > 192.168.10.241.137: UDP, length 50
01:03:11.479934 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 5
01:03:11.624158 IP 65.54.49.80.1863 > 192.168.10.241.2717: tcp 8
01:03:11.761804 IP 192.168.10.241.2717 > 65.54.49.80.1863: tcp 0
01:03:16.497933 IP 192.168.5.28 > 192.168.10.241: ICMP echo request, id 1024, seq 46464, length 24
01:03:16.501866 IP 192.168.5.28 > 192.168.10.241: ICMP echo request, id 1024, seq 50048, length 24
01:03:16.501872 IP 192.168.5.28 > 192.168.10.241: ICMP echo request, id 1024, seq 53632, length 24
01:03:16.565799 IP 192.168.10.241 > 192.168.5.28: ICMP echo reply, id 1024, seq 46464, length 24
01:03:16.583443 IP 192.168.10.241 > 192.168.5.28: ICMP echo reply, id 1024, seq 50048, length 24
01:03:16.585429 IP 192.168.10.241 > 192.168.5.28: ICMP echo reply, id 1024, seq 53632, length 24

Sorry i wasnt meaning that the DHCP entry and the ARP entry were evidence of being able to bypass CP.. just that i can see that the MAC and IP of that client is online and not in the MAC passthough list, and is definately online and surfing, so it is somehow bypassing the CP.

That thought about Squid is an interesting one.. i am just running Squid as a transparent proxy.. can someone with more knowledge of Squid possible give your two cents worth here?

cmb · Nov 21, 2011, 6:45 AM

Transparent proxying bypasses captive portal.

luke240778 · Nov 21, 2011, 4:32 PM

@cmb:

Transparent proxying bypasses captive portal.

Ok, but thats obviously not my problem here right? seeing that his exact same setup worked perfectly fine for over 8 months..

I always had transparent proxy and CP running and all my clients used to get the CP login screen.. now all of a sudden they are getting past it. If i stop the Squid service and try and login a client that is currently bypassing the CP this should prove this?

luke240778 · Nov 28, 2011, 6:04 PM

Ok all, i am seriously needing help here.

I was thinking my captive portal issue may have been my Ruckus AP letting connected clients bypass the CP, but i have just tested with another AP made by Ubiquiti and it also lets people connected bypass the CP.. However, with that same Ubiquiti AP connected to my other NIC (OPT1 and not LAN) the CP kicks in and works like it should. What can possible making 1 interface work and not the other? I have Captive Portal enabled on both LAN and OPT1.

All help is appreciated here, this is starting to be a big issue now as we are expanding a little.

ptt · Nov 28, 2011, 6:11 PM

@luke240778:

Ok all, i am seriously needing help here.

Have you considered the Commercial Support ?

https://portal.pfsense.org/

luke240778 · Nov 28, 2011, 6:19 PM

@ptt:

@luke240778:

Ok all, i am seriously needing help here.

Have you considered the Commercial Support ?

https://portal.pfsense.org/

Have considered it yes. Was hoping that some one on the forum would have been able to assist first, but if i can't get anywhere i guess thats what i'll have to do.