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

    Two lan interfaces DHCP assigning same subnet to both

    Scheduled Pinned Locked Moved DHCP and DNS
    14 Posts 4 Posters 6.8k 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.
    • D
      darksilver
      last edited by

      @kage:

      I set up two LAN interfaces, then went to the DHCP settings and enabled the DHCP for both interfaces

      lan interface:
      Subnet 192.168.1.0
      Subnet mask 255.255.255.0
      Available range 192.168.1.0 - 192.168.1.255
      range: 192.168.1.10 - 192.168.1.150

      OPT1 interfacae:
      Subnet 192.168.2.0
      Subnet mask 255.255.255.0
      Available range 192.168.2.0 - 192.168.2.255
      range: 192.168.2.10 - 192.168.2.150

      seemed to be working ok at first, but then i connected new computers to the network (LAN interface) they were assigned ip's 192.168.2.XXX …. makes no sense to me, OPT1 interface isn't even connected to a switch at all, it uses a crossover cable to connect directly to another computer.

      can anyone say why its assigning 192.168.2.xxx on the LAN interface?

      kyle

      Hi,

      I have the same exact problem Kyle does. I have two LAN Interfaces
      dc0 interface:
      Subnet 192.168.2.0
      Subnet mask 255.255.255.0
      Available range 192.168.2.0 - 192.168.2.255
      range: 192.168.2.6 - 192.168.2.149

      dc1 interface:
      Subnet 192.168.3.0
      Subnet mask 255.255.255.0
      Available range 192.168.3.0 - 192.168.3.255
      range: 192.168.3.1 - 192.168.3.199

      When a new client connects to the LAN interface it gets an ip 192.168.3.199 instead of the 192.168.2.79. From the syslog logs i can see the following:

      DHCPDISCOVER from 08:00:27:c1:ad:22 via dc1
      DHCPDISCOVER from 08:00:27:c1:ad:22 via dc0
      DHCPOFFER on 192.168.3.199 to 08:00:27:c1:ad:22 (organization) via dc1
      DHCPOFFER on 192.168.2.79 {organization.network.net} to 08:00:27:c1:ad:22 (organization) via dc0
      DHCPREQUEST for 192.168.3.199 (192.168.3.250) from 08:00:27:c1:ad:22 (organization) via dc1
      DHCPACK on 192.168.3.199 to 08:00:27:c1:ad:22 (organization) via dc1
      DHCPREQUEST for 192.168.3.199 (192.168.3.250) from 08:00:27:c1:ad:22 (organization) via dc0: wrong network.
      DHCPNAK on 192.168.3.199 to 08:00:27:c1:ad:22 via dc0

      It seems that the broadcast packets (DHCPDISCOVER and DHCPOFFER) always reach both subnets even though they are physically two separate Ethernet ports, and the client PC always gets the higher ip address offered :(
      Does any one know a way to make this  to work ? (I've tried adding firewall rules to block the traffic from one subnet to the other with no success)

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

        darksilver:
        dc0 and dc1 are connected to the same switch? This is a broken configuration for this sort of reason.

        If you really want to isolate dc0 and dc1 put them on separate switches (or separate VLANs if your switch is VLAN capable).

        If you don't want to isolate dc0 and dc1 (having them on the same switch doesn't give any effective isolation) then drop the pretence and use just one interface.

        kage: Do you have the same misconfiguration as darksilver?

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

          @wallabybob:
          dc0 and dc1 are two ethernet ports on my pfsense and they DO NOT have any kind of physical connectivity between them.

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

            @darksilver:

            @wallabybob:
            dc0 and dc1 are two ethernet ports on my pfsense and they DO NOT have any kind of physical connectivity between them.

            Virtual connectivity? A software bridge? A hardware bridge?

            Its pretty unusual that two DHCP requests from the same MAC address should appear on two unconnected networks at around the same time.

            Its possible there is a weird bug in dhcpd. What pfSense version are you running?

            Your DHCP log shows:

            DHCPDISCOVER from 08:00:27:c1:ad:22 via dc1
            DHCPDISCOVER from 08:00:27:c1:ad:22 via dc0
            DHCPOFFER on 192.168.3.199 to 08:00:27:c1:ad:22 (organization) via dc1
            DHCPOFFER on 192.168.2.79 {organization.network.net} to 08:00:27:c1:ad:22 (organization) via dc0
            DHCPREQUEST for 192.168.3.199 (192.168.3.250) from 08:00:27:c1:ad:22 (organization) via dc1
            DHCPACK on 192.168.3.199 to 08:00:27:c1:ad:22 (organization) via dc1
            DHCPREQUEST for 192.168.3.199 (192.168.3.250) from 08:00:27:c1:ad:22 (organization) via dc0: wrong network.
            DHCPNAK on 192.168.3.199 to 08:00:27:c1:ad:22 via dc0

            Note 192.168.3.199 was reportedly offered to a system on dc1 and then a system on dc0 requests that same IP address. How did the system on dc0 get to see the offer supposedly sent on dc1? (I also wondered if you might have two systems with the same MAC address, one visible by dc0 and the other visible by dc1, but that wouldn't explain what's in the log.)

            Did you ever have dc0 and dc1 bridged in pfSense? Maybe it wasn't correctly cleaned out. (I've seen a couple of instances of pfSense 2.0 BETA seemingly remembering parts of a previous configuration of an interface.) Please post the output of the shell command # ifconfig -a

            I guess you could also run some tcpdumps to see if the DHCP requests from the same MAC address really do come in over both dc0 and dc1.

            1 Reply Last reply Reply Quote 0
            • jimpJ
              jimp Rebel Alliance Developer Netgate
              last edited by

              Yes, according to those log entries, something is bridging or combining those broadcast domains.

              It could be a software bridge, a cable between the involved switches, a dual homed host misbehaving, etc, but it's not pfSense deciding to hand out the "wrong" subnet on the "wrong" interface on its own.

              You definitely should not be seeing traffic from the same MAC on both interfaces if they are truly separate.

              Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

              Need help fast? Netgate Global Support!

              Do not Chat/PM for help!

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

                Hi again,

                First of all thank you all for your replies!

                I've connected the dc1 port to a switch with nothing else connected to it. The client PC still gets the wrong ip address (it is a Windows machine). If I disconnect the dc1 port(interface down) it works fine. Unless packets travel by air (like magic… :P) there is not any possible connectivity between both interfaces. But I'm pretty sure this is caused because pfsense for some reason is allowing it.
                I took a wireshark trace of both situations ("normal" : with the dc1 DHCP server off, and "abnormal" : with DHCP server active on both interfaces), and I can see that the DCHPOFFER is coming from to different mac addresses (by the way, it is a 4 port Ethernet card, so that is why the mac are very similar). I believe this could only mean that pfsense is not working as expected or some other obscure configuration is needed...
                I'm using pfsense version 1.2.3

                Wireshark traces attached (please remove jpg extension).

                Regards

                wiresahark.rar.jpg

                1 Reply Last reply Reply Quote 0
                • jimpJ
                  jimp Rebel Alliance Developer Netgate
                  last edited by

                  As requested previously, we need the output of "ifconfig -a" from a shell prompt or Diagnostics > Command

                  Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                  Need help fast? Netgate Global Support!

                  Do not Chat/PM for help!

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

                    Sorry forgot to take that… It is interesting to see that bridge0 has dc0 and dc1... but on the interface configuration of dc1 in pfsense I've set "bridge with" option to none.

                    $ ifconfig -a
                    dc0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
                    options=8 <vlan_mtu>ether 00:06:2b:01:50:ad
                    inet 192.168.2.250 netmask 0xffffff00 broadcast 192.168.2.255
                    inet6 fe80::206:2bff:fe01:50ad%dc0 prefixlen 64 scopeid 0x1
                    media: Ethernet autoselect (100baseTX <full-duplex>)
                    status: active
                    dc1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
                    options=8 <vlan_mtu>ether 00:06:2b:01:50:ae
                    inet6 fe80::206:2bff:fe01:50ae%dc1 prefixlen 64 scopeid 0x2
                    inet 192.168.3.250 netmask 0xffffff00 broadcast 192.168.3.255
                    media: Ethernet autoselect (100baseTX <full-duplex>)
                    status: active
                    dc2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
                    options=8 <vlan_mtu>ether 00:06:2b:01:50:af
                    media: Ethernet autoselect
                    status: no carrier
                    dc3: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
                    options=8 <vlan_mtu>ether 00:06:2b:01:50:b0
                    media: Ethernet autoselect
                    status: no carrier
                    xl0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    options=9 <rxcsum,vlan_mtu>ether 00:0a:5e:20:3a:c5
                    inet6 fe80::20a:5eff:fe20:3ac5%xl0 prefixlen 64 scopeid 0x5
                    inet 192.168.1.64 netmask 0xffffff00 broadcast 192.168.1.255
                    media: Ethernet autoselect (100baseTX <full-duplex>)
                    status: active
                    lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
                    inet 127.0.0.1 netmask 0xff000000
                    inet6 ::1 prefixlen 128
                    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
                    enc0: flags=0<> metric 0 mtu 1536
                    pfsync0: flags=41 <up,running>metric 0 mtu 1460
                    pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
                    pflog0: flags=100 <promisc>metric 0 mtu 33204
                    bridge0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                    ether ce:9f:dd:2a:b3:75
                    id 00:06:2b:01:50:ad priority 32768 hellotime 2 fwddelay 15
                    maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
                    root id 00:06:2b:01:50:ad priority 32768 ifcost 0 port 0
                    member: dc0 flags=1e7 <learning,discover,stp,edge,autoedge,ptp,autoptp>ifmaxaddr 0 port 1 priority 128 path cost 200000 proto rstp
                            role designated state forwarding
                    member: dc1 flags=1e7 <learning,discover,stp,edge,autoedge,ptp,autoptp>ifmaxaddr 0 port 2 priority 128 path cost 200000 proto rstp
                            role designated state forwarding</learning,discover,stp,edge,autoedge,ptp,autoptp></learning,discover,stp,edge,autoedge,ptp,autoptp></up,broadcast,running,simplex,multicast></promisc></up,running></up,loopback,running,multicast></full-duplex></rxcsum,vlan_mtu></up,broadcast,running,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></full-duplex></vlan_mtu></up,broadcast,running,promisc,simplex,multicast></full-duplex></vlan_mtu></up,broadcast,running,promisc,simplex,multicast>

                    1 Reply Last reply Reply Quote 0
                    • jimpJ
                      jimp Rebel Alliance Developer Netgate
                      last edited by

                      That bridge is definitely your problem.

                      What about on dc0, does it also not have a bridge option set?

                      If that persists after a reboot, something in your config is doing it. That doesn't happen by default or automatically.

                      Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                      Need help fast? Netgate Global Support!

                      Do not Chat/PM for help!

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

                        Hi,

                        dc0 also has the "Bridge with" option set to none. However I tried force saving the same configuration again and then rebooted pfsense. And after that, the bridge was gone :)
                        I've enabled the DHCP on both interfaces and now everything works fine(I will do some more tests though!). I remember that some time ago when I first tried to configure the second interface dc1 I've tried to bridge it with some other interface. Even though I think pfsense has been rebooted a few times after that, it seems that for some reason that bridge interface never was removed and that was the reason for this strange behavior.
                        Thank you very much jimp and wallabybob for your support! This forum rules ;)

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