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

    [SOLVED] How do I properly setup DHCP on multiple interfaces in isolation?

    Scheduled Pinned Locked Moved DHCP and DNS
    6 Posts 2 Posters 3.0k 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.
    • T
      tmills
      last edited by

      I'm having some troubles with my setup and am hoping someone can help point me in the right direction.

      What I want to have is multiple interfaces, each with DHCP enabled, but isolated from each other. I have 4 OPT Interfaces active on my pfsense 2.1 box, with the DHCP Server active on 3 of those interfaces, as shown below:

      OPT1: 10.0.1.x
      OPT2: 10.0.2.x
      OPT3. 192.168.2.x

      I have rules on each interface rejecting traffic with a source of the other two subnets, e.g.:

      OPT1 rejects all inbound traffic from OPT2 and OPT3
      OPT2 rejects all inbound traffic from OPT1 and OPT3
      OPT3 rejects all inbound traffic from OPT1 and OPT2

      However clients on OPT1 occasionally get 192.168.2.x addresses and I don't understand why. I am expecting that the rules would prevent the DHCP request from ever reaching the "DHCP servers" listening on the other interfaces and they should also prevent the responses.

      Is there some flaw in my implementation, or is this a known limitation, or???

      Thanks in advance for any help or suggestions.

      T

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

        OPT1 will never see INBOUND traffic from OPT2 or OPT3.

        To keep pfSense from routing between interfaces (assuming typical pass any any rules) you need to, for example, reject traffic INBOUND on OPT2 with destinations of OPT1 net and OPT3 net, followed by the pass any any rule.

        Regarding DHCP, it sounds like there's a layer 2 problem somewhere which is allowing the wrong interface to receive the DHCP request.  DHCP logs show anything interesting when this happens?

        Are each of these interfaces connected to separate LAN segments?  Or are you doing something "different?"

        Does your network look like this?

        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
        • T
          tmills
          last edited by

          Thanks for the reply Derelict…

          The image you posted is essentially my exact layout. The 3 networks are physically segregated. One is the main network, one is wireless only, the other is on the end of a trunk line in another building.

          I changed my rules to reject traffic TO the other networks, so it now looks like this:

          OPT1 rejects all traffic with a destination of OPT2 or OPT3
          OPT2 rejects all traffic with a destination of OPT1 or OPT3
          OPT3 rejects all traffic with a destination of OPT1 or OPT2

          For this test, the computer I am using is physically connected to the OPT1 (sk1) network and wireless (the only access to OPT2 (sk2)) is disabled.

          I am still getting a "bad" IP from DHCP, here are the logs, notice that the DHCPDISCOVER comes in on sk1 (OPT1) and sk2 (OPT2) and both respond with a DHCPOFFER. Somehow there is a DHCPREQUEST on sk2 AND sk1. dhcpd on sk1 realizes this is invalid and issues a DHCPNAK, but the one on sk2 has already ACK'd it...

          Dec 10 18:27:04 dhcpd: DHCPNAK on 192.168.2.215 to d4:be:d9:6d:ef:68 via sk1
          Dec 10 18:27:04 dhcpd: DHCPREQUEST for 192.168.2.215 (192.168.2.1) from d4:be:d9:6d:ef:68 (TYRONEM22345) via sk1: wrong network.
          Dec 10 18:27:04 dhcpd: DHCPACK on 192.168.2.215 to d4:be:d9:6d:ef:68 (TYRONEM22345) via sk2
          Dec 10 18:27:04 dhcpd: DHCPREQUEST for 192.168.2.215 (192.168.2.1) from d4:be:d9:6d:ef:68 (TYRONEM22345) via sk2
          Dec 10 18:27:04 dhcpd: DHCPOFFER on 10.0.1.238 to d4:be:d9:6d:ef:68 (TYRONEM22345) via sk1
          Dec 10 18:27:04 dhcpd: DHCPOFFER on 192.168.2.215 to d4:be:d9:6d:ef:68 (TYRONEM22345) via sk2
          Dec 10 18:27:03 dhcpd: unexpected ICMP Echo Reply from 10.0.1.1
          Dec 10 18:27:03 dhcpd: unexpected ICMP Echo Reply from 70.67.180.1
          Dec 10 18:27:03 dhcpd: DHCPDISCOVER from d4:be:d9:6d:ef:68 (TYRONEM22345) via sk1
          Dec 10 18:27:03 dhcpd: DHCPDISCOVER from d4:be:d9:6d:ef:68 via sk2

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

            Well, that can't happen.

            Either sk1 and sk2 are bridged or both those interfaces are on the same LAN segment.

            What aren't you telling us?  ;)

            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
            • T
              tmills
              last edited by

              Oh man…

              The word "bridged" in your reply totally twigged it for me. The wireless router on sk2 had been connected back into the main network on sk1 to give internet access while the pfsense box was being deployed.

              I just unplugged it and all is right with the world.

              Thanks for taking the time to help out with this, it is greatly appreciated!

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

                Someone crossed the streams.

                Glad it's fixed.

                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
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.