DHCP leases "leak" between interfaces

  • Hi, I have recently switched from vanilla FreeBSD firewall with a lot of custom setup to pfSense as I was getting tired of maintaining all the spaghetti mess I've created over the years.

    I have set up 4-interface pfSense box with 3 ethernet connections:

    1. WAN (DHCP client)
    2. LAN (DHCP server)
    3. WIFI (DHCP server) (this one connects to UniFi AP)

    It is a home network so initially I though I'd keep things simple and allow anything to cross LAN<->WIFI...

    The problem I'm facing is that I've got machines on WIFI getting LAN leases and vice-versa. I took a quick look at the /etc/dhcpd.conf and it looks very similar to what I've used to have with my old vanilla FreeBSD setup.

    Here are the snaps of rules for LAN:
    and WIFI:
    I've added custom "block" rules to stop DHCP requests crossing network boundaries.

    under DHCP server I've got Deny unknown clients for each interface and have all the clients with their MACs provided. Some of them get the proper IP and all is good, but then some do get LAN IP on a WIFI net and vice-versa... and I just can't put my finger on it...

    Here's what DHCP logs look like for a client making a DHCP request on LAN interface (notice how both igb1 and igb2 respond, whereas I'd expect igb1 only): Screenshot_20201015_231038.png

  • Could it be that a wrong lease on the wrong interface would enable the client to access things he shouldnt??

  • Any chance you're running VLANs through a TP-Link managed switch? Some models have a problem where VLAN1 appears on all VLANs.

  • @JKnott that indeed happened to be the case with my NetGear switch assigning VLAN1 to all the untagged interfaces... šŸ¤¦ took me a while to convince it otherwise and now things seem to be OK. Although I'm surprised now that dhcpd was OK assigning cross-network IPs despite explicit instructions to give IP to a specific MAC from a specific LAN... odd behavior I must say.

  • This happened to me using a TL-SG108E HW2.0 (TP Link cheap switch).

Log in to reply