Client receives a guest VLAN address after an access port is assigned to the wrong VLAN

Problem

A workstation that previously opened an internal web page stops reaching it after a switch access-port change. The browser cannot open the service by IP address. DHCP still gives the workstation an address, so this is not necessarily a DHCP outage.

Environment and expected behaviour

This article documents a controlled Cisco Packet Tracer lab, not a production incident. The simplified topology uses a Cisco 2960 switch, a router with 802.1Q subinterfaces, DHCP pools on the router and an extended ACL applied inbound on the guest subinterface.

The user workstation connects to switch Fa0/1. The server connects to Fa0/4. Switch Gig0/1 is an 802.1Q trunk to the router. The router's GigabitEthernet0/0.30 subinterface has an inbound ACL denying 192.168.30.0/24 to 192.168.20.0/24.

Normally, Fa0/1 belongs to VLAN 10 and the workstation can open http://ikw.test or http://192.168.20.20. A guest workstation cannot reach the server by IP. Names, addresses and interfaces here identify only the synthetic lab.

Observed behaviour and evidence

For the exercise, Fa0/1 was deliberately reassigned to VLAN 30. After a DHCP renewal, the router showed a new lease 192.168.30.22 for the same client identifier that had earlier leased 192.168.10.21. The old lease remained in show ip dhcp binding; that table alone does not prove which address is currently configured on the PC.

The switch output placed Fa0/1 and the existing guest port Fa0/3 in VLAN 30, while VLAN 10 had no access ports. show interfaces trunk on the switch showed Gig0/1 trunking and forwarding VLANs 10, 20 and 30. The router ACL deny counter had accumulated matches. The page became available again after Fa0/1 was returned to VLAN 10 and DHCP was renewed.

The ACL counter is cumulative. Its value alone does not identify the workstation or prove that a particular browser attempt was blocked. For a controlled comparison, record it before and after a new test.

Likely causes to distinguish

• The access port is assigned to the wrong VLAN.
• The PC retains an old address or gateway after a port move.
• The VLAN is missing from the trunk.
• The router subinterface or route is down.
• An ACL blocks the source subnet.
• DNS resolution fails while direct IP access still works.
• The web service is unavailable to multiple otherwise healthy clients.

Diagnostic workflow

1. Check the workstation's current address

On the affected Packet Tracer PC, open Desktop > Command Prompt:

ipconfig
ping 192.168.20.20

Record the IP address, mask and default gateway. An address in 192.168.30.0/24 with gateway 192.168.30.1 indicates that the PC currently behaves as a guest client. A failed ping or direct-IP browser request narrows the problem beyond DNS, but does not yet identify the exact blocking device.

2. Check access-port membership on the switch

Run these at the privileged Switch# prompt:

show vlan brief
show interfaces trunk

show vlan brief maps access ports to VLANs. In this lab, Fa0/1 appeared under VLAN 30, not VLAN 10. show interfaces trunk verifies that Gig0/1 is trunking and that the relevant VLANs are active and forwarding. This command belongs on the switch; running it on the router does not display the switch trunk.

If you are at Switch(config-if)#, use end first or prefix a diagnostic command with do.

3. Correlate DHCP and ACL on the router

Run these at the privileged Router# prompt:

show ip dhcp binding
show ip interface brief
show access-lists

show ip dhcp binding identifies the lease and client identifier; compare it with the workstation's current ipconfig. A client identifier may have both an old and a new lease after a VLAN change.

show ip interface brief helps confirm that the router subinterfaces are operational. show access-lists displays deny and permit entries and their cumulative match counts. The lab's guest ACL contains a deny from 192.168.30.0/24 to 192.168.20.0/24, followed by a general permit for other destinations.

Confirmed root cause

The controlled fault was the access VLAN assignment of Fa0/1. The PC joined VLAN 30, received a guest-subnet DHCP lease and was then subject to the guest-to-servers ACL. The trunk was operational, so changing trunk settings would not address this fault.

Resolution

First verify that Fa0/1 is the intended user port and that VLAN 10 is the approved segment. On the switch:

enable
configure terminal
interface fastEthernet0/1
 switchport access vlan 10
end
write memory

On the Packet Tracer PC, renew its DHCP configuration under Desktop > IP Configuration by selecting Static, then DHCP. In a real environment, use the endpoint's normal DHCP renewal method and follow change controls for the switch port.

Validation

1. show vlan brief lists Fa0/1 under VLAN 10.
2. ipconfig on the workstation shows an address in 192.168.10.0/24 and gateway 192.168.10.1.
3. http://192.168.20.20 opens from the user workstation. http://ikw.test also opens when its DNS setting is correct.
4. A guest workstation still fails to reach 192.168.20.20 by IP.
5. The switch trunk remains forwarding the expected VLANs.

The lab operator confirmed that access to the site returned after the correction. The recorded outputs establish the wrong switch VLAN and the guest-subnet DHCP lease; they do not include a captured post-correction ipconfig.

Rollback and prevention

If the port was intentionally assigned to the guest network, return it to the documented previous VLAN rather than assuming VLAN 10 is universally correct. Record the port's original settings before any production change and verify the affected user and security policy afterward.

For the full simulated network, see Build a segmented small business network in Packet Tracer.

Maintain a port-to-device inventory, document intended VLANs, and compare the client's current IP/gateway with show vlan brief early in any single-client connectivity investigation. Avoid weakening the guest ACL to compensate for a misassigned access port.