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

    Wired clients don't get IP, only wireless clients ???

    Scheduled Pinned Locked Moved DHCP and DNS
    4 Posts 2 Posters 836 Views
    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.
    • P Offline
      pfsensitive
      last edited by

      Thanks for a great firewall!

      I'm running pfsense 2.2.4 and Netgear switches/AP (GS105E, GS108T, GS110TP, GS724T, WNAP320).

      WNAP320(WIFI) -> GS110TP <- GS108T <- GS105E (some wired clients)
                                        |
                                  GS724 -> pfsense

      All my Wireless clients get their address as expected by scope (some) or IP binding (most), but my wired clients do not. So if I connect a client that has both available (say Laptop), then it connects fine (not at the same time) through wifi but not with cable. It don't get the IP from DHCP, then. If I assign a static ip to the clients LAN-port, all works fine, but for me that's not a solution, only a workaround for now.

      Looking in the DHCP log I can see this:
      Aug 4 02:03:00 dhcpd: DHCPOFFER on 192.168.0.115 to 98:d6:bb:xx:xx:xx via vr0
      Aug 4 02:03:00 dhcpd: DHCPDISCOVER from 98:d6:bb:xx:xx:xx via vr0

      There should perhaps also be an DHCPREQUEST and DHCPACK too…?

      What I see in the Firewall log, is that it is blocking addresses at 169.254... on port 137 (UDP), "Block IPv4 local-link". I have registered that this might be related to the 2.2.4 update.

      Any idea how to solve this?

      Please ask for more info if needed. I'm not an experienced user...

      Thanks in advance.

      1 Reply Last reply Reply Quote 0
      • DerelictD Offline
        Derelict LAYER 8 Netgate
        last edited by

        @pfsensitive:

        Thanks for a great firewall!

        I'm running pfsense 2.2.4 and Netgear switches/AP (GS105E, GS108T, GS110TP, GS724T, WNAP320).

        WNAP320(WIFI) -> GS110TP <- GS108T <- GS105E (some wired clients)
                                          |
                                    GS724 -> pfsense

        All my Wireless clients get their address as expected by scope (some) or IP binding (most), but my wired clients do not. So if I connect a client that has both available (say Laptop), then it connects fine (not at the same time) through wifi but not with cable. It don't get the IP from DHCP, then. If I assign a static ip to the clients LAN-port, all works fine, but for me that's not a solution, only a workaround for now.

        Looking in the DHCP log I can see this:
        Aug 4 02:03:00 dhcpd: DHCPOFFER on 192.168.0.115 to 98:d6:bb:xx:xx:xx via vr0
        Aug 4 02:03:00 dhcpd: DHCPDISCOVER from 98:d6:bb:xx:xx:xx via vr0

        Are those the wired MAC that isn't working?

        There should perhaps also be an DHCPREQUEST and DHCPACK too…?

        There certainly should.  But the ball is in the client's court since the router sent DHCPOFFER.

        My next step would be to pull out my tester and plug it into the same port and see if it gets DHCP.  If that failed I would make sure there is good two-way traffic everywhere.  The DHCPDISCOVER makes it from the client to pfSense but the DHCPOFFER might not be making it from pfSense to the client.  Check the cables daisy-chaining your switches together, all the switch ports, etc.  Check the VLANs if you're using them.  I suppose it might be possible for a port that had the same VLAN as a PVID on one side and tagged on the other could possibly result in one-way traffic.

        After that I would packet sniff to see what's going on.

        What I see in the Firewall log, is that it is blocking addresses at 169.254… on port 137 (UDP), "Block IPv4 local-link". I have registered that this might be related to the 2.2.4 update.

        That's just because the client doesn't have a DHCP address.  Fix DHCP and you'll fix that.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • P Offline
          pfsensitive
          last edited by

          Thanks for your fast reply!
          There are several MACs that doesn't work, this was only an example.

          Now I have some steps to try out.

          But I tried one thing right away:
          I connected my laptop directly to GS724 (LAN). After about 30 sec. it received its IP address !
          I disconnected the cable and plugged it in again after a few seconds. Then it received IP address almost immediately.

          Then I went back to the GS105 to try there. After a while it actually received IP there too, but it took longer time, maybe 50-60 seconds (every time).

          Does this mean anything to you that would lead me faster to the problem or do you still recommend the above mentioned tests?
          It seems that by connecting it directly to GS724, it was later accepted by the other switches…

          I do not have any test-tool ready (I will have some day), so I hope for a quick fix this time...

          I guess I will continue this thread in a Netgear forum if I can't solve this myself now, since this seems to be related to my switches and not pfsense. But You have been so helpful and any tips and/or ideas are welcome...  :)

          1 Reply Last reply Reply Quote 0
          • P Offline
            pfsensitive
            last edited by

            Problem solved!

            After some testing I found that the GS108T had to be the weak point.

            So I did a check in the configuration and found that it had DHCP filter enabled, but not configured. So I turned it off and all of a sudden things start to work as it should.

            Thanks again!

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