VLAN discovery and responsible disclosure
Internal addressing, segment names, and the specific policy gaps are deliberately left out of this write-up. The point here is the process. I am happy to talk through the technical detail in person.
Summary
Two segments of the same campus network enforce different security policies. Traffic that worked from my wifi devices was blocked on the wired port used by my home lab server. 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
The server runs on a wired connection. Every other device 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 tested. Same user, same building, same network, different result.
Method
Nothing here involved scanning other people's machines or trying to get anywhere I was not 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 applies depends on the socket a device is plugged into rather than the authenticated user. The same user therefore gets a different security posture depending on physical location, and the network gives no indication of which segment a device is in.
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
- Most of the effort was in the reporting, not the discovery. Packet captures and notes had to become a document a network team could read and act on.
- Stating the scope up front, including what was not tested, kept the disclosure straightforward. The report was handled on its merits.
- A policy split of this kind is a product of infrastructure changing over time rather than a single decision, which is why it needs to be recorded when someone notices it.
More write-ups: Hardened home lab server · SSH brute-force alerter