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

    Captive Portal blocks WiFi-network access [SOLVED]

    Captive Portal
    3
    7
    2.4k
    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.
    • G
      gregoryzero
      last edited by

      Good day everyone!

      I'am using pfSense 2.1.2-RELEASE (i386) as a gateway, captive portal and dhcp-server.
      pfSense has 4 interfaces configured (WAN LAN WIFI and OPT) all dhcp-server enabled, DNS forwarder also enabled.

      Also, I have configured 3 Wifi-networks on UBIQUITY WiFi-controller:

      1 - guest network for clients (segregated from others by VLAN)
      2 - network for work and personal usage
      3 - test network.

      The problem is - When I enable captive portal on interface OPT, and connect to WiFi-network 2 or 3, my device receives IP-adress 10.1.., which is correct, and I can authenticate, connect and browse the web.
      But, if try to connect to network 1 (guest network), my device receives IP-adress 169.254..* which is wrong and I have no Internet connection…
      When captive portal is disabled, every WiFi-network works fine.

      Where is the problem?

      1 Reply Last reply Reply Quote 0
      • H
        heper
        last edited by

        do you have the vlans trunked between the wifi and pfsense ? does each vlan have an interface assigned in pfsense ? is there a switch between pfsense & the wifi controller, how is that configured ?

        1 Reply Last reply Reply Quote 0
        • G
          gregoryzero
          last edited by

          @heper:

          do you have the vlans trunked between the wifi and pfsense ? does each vlan have an interface assigned in pfsense ? is there a switch between pfsense & the wifi controller, how is that configured ?

          I have 4 TP-Link TL-SG2424 switches linked together by Cat5 cord.

          Switches wich serve WiFi AP's, have VLANs ports set to:

          Link Type - GENERAL
          Egress Rule - TAG

          WIFI interface in pfsense has corresponding VLAN configured on all 4 TP-Link switches
          OPT interface in pfsense has corresponding VLAN configured on TP-Link switch 1

          1 Reply Last reply Reply Quote 0
          • GertjanG
            Gertjan
            last edited by

            @gregoryzero:

            …..
            But, if try to connect to network 1 (guest network), my device receives IP-adress 169.254..* which is wrong and I have no Internet connection...

            This seems normal to me.
            These IP's are auto-assigned IP's.
            That means, if a DHCP request isn't answered by any DHCP server in x time, the device auto-assigns itself an IP.
            These are always in the "169.254.." range.
            And yes, the client 'made up" this IP by isself, but there wil be no Gateway, no DNS, no nothing.
            "169.254.
            .**" isn't even routable, so …. no "Internet".

            So: on "network 1", no DHCP requests are passed to a DHCP server (or: the reply won't make it back).
            In both cases: the log of the DHCP server will shed some more light.

            No "help me" PM's please. Use the forum, the community will thank you.
            Edit : and where are the logs ??

            1 Reply Last reply Reply Quote 0
            • G
              gregoryzero
              last edited by

              @Gertjan:

              @gregoryzero:

              …..
              But, if try to connect to network 1 (guest network), my device receives IP-adress 169.254..* which is wrong and I have no Internet connection...

              This seems normal to me.
              These IP's are auto-assigned IP's.
              That means, if a DHCP request isn't answered by any DHCP server in x time, the device auto-assigns itself an IP.
              These are always in the "169.254.." range.
              And yes, the client 'made up" this IP by isself, but there wil be no Gateway, no DNS, no nothing.
              "169.254.
              .**" isn't even routable, so …. no "Internet".

              So: on "network 1", no DHCP requests are passed to a DHCP server (or: the reply won't make it back).
              In both cases: the log of the DHCP server will shed some more light.

              DHCP-server log shows this:

              dhcpd: send_packet: Permission denied
              Failed to send 300 byte long packet over bce1_vlan30 interface
              
              1 Reply Last reply Reply Quote 0
              • GertjanG
                Gertjan
                last edited by

                @gregoryzero:

                DHCP-server log shows this:

                dhcpd: send_packet: Permission denied
                Failed to send 300 byte long packet over bce1_vlan30 interface
                

                Well, that's clear enough.

                I guess: undo all the vlan-stuff and all starts working. Start digging in that direction.

                No "help me" PM's please. Use the forum, the community will thank you.
                Edit : and where are the logs ??

                1 Reply Last reply Reply Quote 0
                • G
                  gregoryzero
                  last edited by

                  @Gertjan:

                  @gregoryzero:

                  DHCP-server log shows this:

                  dhcpd: send_packet: Permission denied
                  Failed to send 300 byte long packet over bce1_vlan30 interface
                  

                  Well, that's clear enough.

                  I guess: undo all the vlan-stuff and all starts working. Start digging in that direction.

                  It seems, that everything will be easier…
                  I applied the 2.1.4 update and it seems, that this issue has been resolved.
                  Thanks everyone for help.

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