I've got a situation where a DHCP server on a supposedly-isolated VLAN is giving out addresses to clients on VLAN1. I think I'm close to understanding why, but not close enough to sleep well.
We've got several VLANs; those of interest are:
VLAN1 - most PCs in a Win2003 domain, with a DHCP server for Vlans 1 and 2
VLAN2 - IP phones
VLAN5 - a 2nd Win2003 domain with its own DHCP server
A 3550 switches at L3 among VLANs, with a helper address on VLAN2 pointing to the DHCP server on VLAN1. There is no helper anywhere pointing to or from VLAN5.
Until yesterday, everything worked fine, as expected. A typical switchport supporting a phone and a PC was configured as:
interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1,2,1002-1005
switchport mode trunk
switchport voice vlan 2
switchport priority extend cos 0
Since it was working, I fixed it by removing the "trunk allowed" statements from all the end-user switchports. The intent was to allow the upcoming addition of several new VLANs without having to worry about whether they were blocked.
Today, however, as leases began to expire on the VLAN1 clients, many of them obtained VLAN5 addresses. My question is, how is the DHCPDISCOVER getting to the VLAN5 DHCP server, and since the server's responses should be tagged as VLAN5, how are they getting back to the client on VLAN1?
The discover packet must be arriving as a non-helped request, since if it had gone through a helper, the GIADDR field would implicitly solicit an address in the requestor's subnet.
The discover packet is on VLAN1 and thus crosses all trunks, so I'm thinking it shows up as an untagged packet on the switch the VLAN5 DHCP server is on. Its switchport is configured like so:
interface FastEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 5
switchport mode trunk
switchport voice vlan 2
switchport priority extend cos 0
Here's where I get lost. The "trunk native" statement assures that untagged frames arriving on the port are assigned to VLAN5, but I don't think it would prevent outgoing untagged frames from reaching the attached PC, in this case the DHCP server. So, the DHCP server responds with a DHCPOFFER, another broadcast, but shouldn't this be contained on VLAN5? Somehow, the complete DHCP transaction succeeds, the client on VLAN1 obtains a VLAN5 IP address, and can't talk to anybody any more.
Is this a security hole as well? Looks like a way for traffic to cross VLANs without benefit of a router. If someone can tell me what I'm missing, I'd appreciate it. For now, I'm putting back the "allowed" statements; looks like a good practice is to always place an "allow" allowing only VLANs associated with the phone and the native VLAN, and, incidentally, to not use VLAN1 at all.
