VLAN discovery and responsible disclosure

2026 · independent research · reported and acknowledged

Internal addressing, segment names, and the specific policy gaps are deliberately left out of this write-up. The point here is the process. I'm happy to talk through the technical detail in person.

Summary

While running my home lab server on the university network, I noticed that traffic which worked fine from my wifi devices was being blocked on the wired port the server uses. Digging into why led me to a dual-VLAN architecture where two segments of the same campus network enforce noticeably different security policies. I documented the difference, wrote a findings report, and sent it to the VUW network engineering team, who escalated it to the cybersecurity team. The findings were formally acknowledged and reviewed.

Context

My server lives in a hall common room on a wired connection. Everything else I own connects over wifi. A VPN client that connected without issue from every wifi device would not complete a handshake from the server, on any protocol or port I tried. That asymmetry was the starting thread: same user, same building, same network, different behaviour.

Method

Nothing here involved scanning other people's machines or trying to get anywhere I wasn't already allowed to be. Everything was tested from my own devices, on my own accounts, using normal connectivity.

• Compared DHCP leases. The wired and wireless devices were landing in different subnets with different gateways, which pointed to separate VLANs rather than a single flat network.
• Worked out what the policy keys on. I switched the server from static addressing to DHCP on the same port and it came back inside the same restricted segment. So the segmentation followed the switch port, not the device or its registration.
• Mapped the policy differences. From each segment I tested the same set of protocols and recorded what was permitted and what was silently dropped, using Wireshark and tcpdump captures to confirm where traffic actually died rather than guessing from timeouts.

Findings

The two segments enforce materially different egress policies. One is permissive, one is restrictive, and which one you get depends on which socket you plug into rather than who you are. The interesting part wasn't any single blocked protocol. It was the inconsistency: the same user gets a different security posture depending on physical location, and nothing about the network makes that visible to the user or, apparently, consistent by design.

I wrote this up as a short report: what I observed, how I verified it, and why an unintended policy split might matter, with the captures as supporting evidence.

Disclosure

• noticeSpotted the wired/wifi behaviour difference while maintaining the server.
• verifyConfirmed the segmentation and policy split through repeatable tests over several evenings.
• reportSent the written findings to the VUW network engineering team through official channels.
• escalateNetwork engineering escalated the report to the university's cybersecurity team.
• outcomeFindings formally acknowledged and reviewed. Closed out May 2026, with any architecture changes left to the university's own timeline.

What I learned

• Finding something is maybe a third of the work. Turning packet captures and notes into a report that a busy network team can read, trust, and act on is the part that actually took effort.
• Going through proper channels works. Being clear up front about what I did and didn't do made the conversation easy, and the teams treated a first-year student's report seriously.
• Enterprise networks accumulate history. A policy split like this isn't necessarily a mistake by any one person. It's what happens when infrastructure grows over years, and that's exactly why it needs someone to notice and write it down.