DHCP server of the wrong interface serves up IPs
-
@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.
-
@dominikhoffmann said in DHCP server of the wrong interface serves up IPs:
Correct! That’s how it is. Both are on physically separate switches, though, which is why this is all the more confounding.
Why would that matter? As far as you said, the wireless is the only problem. The wired, which you say is on a separate switch, is fine, correct? So don't waste time with it. Look at the other switch.
Are the AP(s) vlan capable?
Are you sending the correct vlans?Maybe you have the SSID's misconfigured and you're actually connecting to the 'old' .14.0/24 network?
Can you confirm the wifilan interface is set to the 15.0/24 network?
-
@jarhead said in DHCP server of the wrong interface serves up IPs:
Why would that matter? As far as you said, the wireless is the only problem. The wired, which you say is on a separate switch, is fine, correct? So don't waste time with it. Look at the other switch.
As it is, I have seen hosts that had been on the physical switch on the 192.168.15.1/24 subnet reacquire the IP addresses they had obtained on that subnet, after they were physically connected to the switch on the 192.168.14.1/24 subnet. In other words, the DCHP server leakage across the subnets is bidirectional.
Maybe you have the SSID's misconfigured and you're actually connecting to the 'old' .14.0/24 network?
Can you confirm the wifilan interface is set to the 15.0/24 network?
I cannot confirm that at the moment, because something is wrong with the VPN into that system. Still, all APs are on the 192.168.15.0/24 subnet as is evidenced in the UniFi OS Console managing them.
-
@dominikhoffmann
Are you using Ubuiqiti switches?
If so, you probably have each port set to "allow all vlans" maybe?
Post screenshots of the switch configs -
@jarhead said in DHCP server of the wrong interface serves up IPs:
Are you using Ubuiqiti switches?
The switches are Netgear switches. The VPN to that network is down right now, so I cannot show the VLAN setup there. However, There is a dedicated, physically separate switch for each subnet. Each switch has an IP address corresponding to the subnet it is physically on.
The only Ubiquiti hardware are the APs and the console.
-
I want to come back to this to post that I have solved this problem.
My issue was that I had a bridge defined in Interfaces → Bridges. It bridged all my internal interfaces, except the guest and IoT interfaces. This allowed DCHP requests to leak through from one interface to the DHCP server running on another.
Doh!
I had done that, because I wanted to Bonjour-browse all my Apple devices, regardless of which subnet they were in. The Asahi package now accomplishes the same thing.