Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Anyone else running a WiSP and using pfSense?

    General pfSense Questions
    8
    45
    20.5k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C
      cmb
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • L
        luke240778
        last edited by

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

        1 Reply Last reply Reply Quote 0
        • D
          dhatz
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • L
            luke240778
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • pttP
              ptt Rebel Alliance
              last edited by

              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

              1 Reply Last reply Reply Quote 0
              • L
                luke240778
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • W
                  wallabybob
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • L
                    luke240778
                    last edited by

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

                    1 Reply Last reply Reply Quote 0
                    • W
                      wallabybob
                      last edited by

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

                      1 Reply Last reply Reply Quote 0
                      • L
                        luke240778
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • C
                          cmb
                          last edited by

                          Transparent proxying bypasses captive portal.

                          1 Reply Last reply Reply Quote 0
                          • L
                            luke240778
                            last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • L
                              luke240778
                              last edited by

                              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.

                              1 Reply Last reply Reply Quote 0
                              • pttP
                                ptt Rebel Alliance
                                last edited by

                                @luke240778:

                                Ok all, i am seriously needing help here.

                                Have you considered the Commercial Support ?

                                https://portal.pfsense.org/

                                1 Reply Last reply Reply Quote 0
                                • L
                                  luke240778
                                  last edited by

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

                                  1 Reply Last reply Reply Quote 0
                                  • First post
                                    Last post
                                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.