DHCP server of the wrong interface serves up IPs
-
I did a network reconfiguration for a client and set up a network with several subnets. One interface is for wired hosts and a second is for WiFi hosts. Each have their own DHCP servers running.
What I have noticed is that clients who connected to WiFi before the WiFi interface was defined will repeatedly obtain their old 192.168.14.0/24 IP address, even though they are physically and logically connected to an interface with a 192.168.15.0/24 subnet.
I don’t see, how I can prevent DHCP clients from getting those old IP addresses back.
What is going on? Is this normal or a bug?
-
I do think that this is not the right way to go about it, but I put two sets of firewall rules in place to prevent this from happening, even though my problem shouldn’t happen in the first place:
LAN is the interface with a DHCP server providing addresses for the 192.168.14.0/24 subnet:
WIFILAN is the interface with a DHCP server providing addresses for the 192.168.15.0/24 subnet:
Only time will tell, whether this will prevent any leakage of requests from one subnet made to the DHCP server of the other. If it doesn’t, we’ll certainly have a piece of evidence leading to the solution.
-
@dominikhoffmann There is no possible way for that to happen if your networks were actually isolated at layer 2 - which clearly they must not be.
-
Yup, agreed. Check your switch. Plugged into the wrong port or vlan set incorrectly.
-
@dominikhoffmann also those rules wouldn't do anything, because there are hidden rules that allow for dhcp that are evaluated before any rules on the specific interface.
Notice they have zero hits - the 0/0 B
example couple of my interfaces.
[22.05-RELEASE][admin@sg4860.local.lan]/root: cat /tmp/rules.debug | grep DHCP
# allow access to DHCP server on LAN pass in quick on $LAN proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000002541 label "allow access to DHCP server" pass in quick on $LAN proto udp from any port = 68 to 192.168.9.253 port = 67 ridentifier 1000002542 label "allow access to DHCP server" pass out quick on $LAN proto udp from 192.168.9.253 port = 67 to any port = 68 ridentifier 1000002543 label "allow access to DHCP server" # allow access to DHCP server on WLAN pass in quick on $WLAN proto udp from any port = 68 to 255.255.255.255 port = 67 ridentifier 1000003591 label "allow access to DHCP server" pass in quick on $WLAN proto udp from any port = 68 to 192.168.2.253 port = 67 ridentifier 1000003592 label "allow access to DHCP server" pass out quick on $WLAN proto udp from 192.168.2.253 port = 67 to any port = 68 ridentifier 1000003593 label "allow access to DHCP server"How would they even get the same IP? Since the mac of the wired interface of device is not going to be the same as the mac of the wireless interface.
-
@johnpoz: That’s what I thought, too. So, now I am wondering, how they are not isolated at Layer 2. While we are on that, at what layer does the firewall operate?
-
@dominikhoffmann It's a router.... so Layer 3.
-
@johnpoz said in DHCP server of the wrong interface serves up IPs:
How would they even get the same IP? Since the mac of the wired interface of device is not going to be the same as the mac of the wireless interface.
If, as you are concluding, there is no complete isolation of the two interfaces and subnets, a wireless client can pick up an IP address from the DHCP server meant to provide them for the subnet reserved for wired clients. In my case, both subnets are served by two different physical ports of the SG-2100 I am using:
The physical ports relate to the VLAN tags like this:
My interfaces LAN and WIFILAN are assigned to the ports like this:
And the VLAN switching is like this:
It’s the last one I feel might be the culprit. I have never been really clear, what needs to happen here. I am eager to learn!
-
@jarhead said in DHCP server of the wrong interface serves up IPs:
It's a router.... so Layer 3.
It’s clear, I need to bone up on the OSI model.
-
@dominikhoffmann
You have 3 networks on port 1, but you said you are using separate physical interfaces.
You also have then tagged, if they really are separate, they should be untagged.
And your WIFI LAN is the untagged on that port so that probably explains why you're still getting the old IP's, you're still connected to the old network. -
@dominikhoffmann said in DHCP server of the wrong interface serves up IPs:
a wireless client can pick up an IP address from the DHCP server meant to provide them for the subnet reserved for wired clients
Agreed - but they wouldn't get the same IP, their macs are different.. I guess its possible if the lease was actually released the dhcp on that network could hand out the same IP again to a different mac..
But if you were actually isolated there is no way what is happening could happening - the only thing that would allow client to get an IP from wrong dhcp is they are actually on the same L2 - or the dhcp server could never see that traffic.
-
@johnpoz said in DHCP server of the wrong interface serves up IPs:
@dominikhoffmann said in DHCP server of the wrong interface serves up IPs:
a wireless client can pick up an IP address from the DHCP server meant to provide them for the subnet reserved for wired clients
Agreed - but they wouldn't get the same IP
I don't think he ever said they get the 'same' IP, just on the same subnet.
-
@dominikhoffmann said in DHCP server of the wrong interface serves up IPs:
will repeatedly obtain their old 192.168.14.0/24 IP address
That is how I read that - but maybe he meant to say an IP in that range and not their "old" one..
Yeah "an" IP would make sense if in the wrong L2 or joined L2s - but not the same one ;)
-
@johnpoz said in DHCP server of the wrong interface serves up IPs:
@dominikhoffmann said in DHCP server of the wrong interface serves up IPs:
will repeatedly obtain their old 192.168.14.0/24 IP address
I apologize for my lack of clarity!
What I had meant by that was that a host that had been on the 192.168.14.0/24 subnet, before somewhat later I set up the physically separate 192.168.15.0/24 subnet, which I reserve for hosts connecting via WiFi, picked up the same IP address, even after being on the physically separated network. I was referring to my access points, which, though connected through an Ethernet backhaul, are assigned 192.168.15.0/24 addresses.
Have I cleared it up or further muddled the waters?
-
@jarhead said in DHCP server of the wrong interface serves up IPs:
You have 3 networks on port 1
Which are you referring to? Port 1 in the listing of 2100 Switch Ports?
That physical port is connected to a managed PoE switch, which powers the access points. Its members are:
- the untagged traffic on that network segment,
- the tagged traffic of hosts on (1) a guest SSID and (2) a “VMS” SSID.
The way I understand it, the setup VLAN group 1’s and 2’s members ensures that the tagged traffic is forwarded to the router, where they are identified with the two corresponding interfaces based on the VLAN tag. The fact that VLAN group 5 also has a “5t” in it, I don’t fully understand. It’s duplicated from a setup I am using on an SG-1100:
In other words, why would VLAN group 5 and 6 (back to the SG-2100 now) not have the members set up as “1,5” and “4,5,” respectively?
If either of you could elucidate that, I would be very grateful.
-
@johnpoz said in DHCP server of the wrong interface serves up IPs:
There is no possible way for that to happen if your networks were actually isolated at layer 2 - which clearly they must not be.
Back to your statement from way up top, now that you see the salient elements of my configuration? Do you see a flaw and therefore, what I need to change and how so?
-
@dominikhoffmann
They should be 1,5t and 4,5t, but you don't have them like that.
You have them both on 1.Again, you said they have separate interfaces now, is that true?
If so, they should not be tagged, no need to as they are the only network on each interface.
I'll throw this out first, I never used a Netgate appliance with a built-in switch but as I understand it, the members are the switchports.
So for vlan 16, the members should be 1,5t (or 4,5t if that's the way you connected them) with 1 being the untagged switchport and 5t being the WAN.
Vlan 17 should be 4,5t (or 1,5t).
You have them both tagged on port 1 which would be fine if you're breaking them out in your managed switch.
You said separate interfaces, so then separate them.EDIT:
Just noticed you said groups 5 and 6... I think I mistook the vlan 16 and 17 as the networks you have changed.
Am I right with that? -
@jarhead: The numbering of the ports is different between the SG-1100 and the SG-2100. This is what the SG-1100 has:
Showing again the SG-2100’s:
In other words, what’s a “0” on the SG-1100 has to be a “5” on the SG-2100.
Yes, on the SG-2100 the LAN and WIFILAN interfaces are on separate physical ports. On the SG-2100 I just duplicated, what was the default on the SG-1100: “0t,1” and “0t,2.” Those became “1,5t” and “4,5t.”
-
@dominikhoffmann
Yes, 5 is the uplink to the wan just as 0 is the same on the 1100.Double check the wifilan interface, if that is set to the 15.0/24 network, then it looks like your problem is gonna be in the managed switch.
From what I see, the 'new' wifi is the untagged on port 1.
The new wired is port 4.
For some reason I was thinking vlans 16 and 17 were the new network, my mistake.
Are the AP(s) vlan capable?
Are you sending the correct vlans? -
@jarhead said in DHCP server of the wrong interface serves up IPs:
From what I see, the 'new' wifi is the untagged on port 1.
The new wired is port 4.Correct! That’s how it is. Both are on physically separate switches, though, which is why this is all the more confounding.
Are the AP(s) vlan capable?
They are Ubiqiti U6-Pros and U6-Lites, and yes they are. Those VLANs are associated with specific SSIDs, one is for guests. I have the corresponding interfaces firewalled from the rest of the internal network, and I have verified that that works.
Are you sending the correct vlans?
Can you tell me, what makes you ask that? I have no reason to doubt it, because, apart from the DHCP quirks, everything works as expected.