A Public Network Treats Every Device as Hostile

When I plan a network for a public space — guest Wi-Fi, a venue, a room full of machines that strangers will sit down at — the design starts from one assumption that quietly rewrites everything else: every device on this network is potentially hostile. Not because the people are malicious, but because you don’t control the endpoints, you can’t vouch for any of them, and on a shared network one compromised laptop is a threat to all its neighbors. “Internal” stops being a synonym for “trusted” the instant the public can connect.

”Internal” stops meaning “trusted”

A lot of network security leans on a soft assumption: stuff inside the perimeter is friendly, stuff outside is suspect. That assumption is doing real work in most office and home networks, and it completely falls apart on a public one. There is no friendly inside. The device next to yours might be running anything, patched to anything, owned by anyone.

So the mental model I use for a public segment is: treat the LAN like the open internet. Anything that would be reckless to expose to the internet is reckless to expose to the guest VLAN, because functionally they’re the same threat surface. That reframing makes the rest of the decisions fall out naturally.

Segment by trust, not by convenience

The backbone of a sane public network is VLAN segmentation drawn along trust lines, not along whatever’s easiest to wire. A rough split I keep coming back to:

• Primary workload — the machines doing the actual job, and the infrastructure that serves them.
• Management — switch, router, and access-point admin interfaces, locked to administrators only.
• Staff / point-of-sale — front-desk and payment systems, kept away from public traffic.
• Guest — internet-only, isolated from every other segment.

Each VLAN is a trust boundary with a firewall between it and the others. The guest segment can reach the internet and nothing else. The management segment is reachable only from admin. The value isn’t the diagram; it’s that a compromise on one segment doesn’t automatically become a compromise of the others.

Client isolation is a setting you have to turn on

Here’s the gap people miss: putting devices on the same guest VLAN doesn’t isolate them from each other. By default, everything on a segment can talk to everything else on that segment. On a public network that’s exactly the wrong default — it means one infected device can scan and attack every other guest directly, never touching your firewall.

On a guest network, the device-to-device path is the attack you’re most likely to forget, because it never crosses a boundary you’re watching.

Client isolation — preventing peers on the same segment from reaching one another — is a deliberate setting, and on a public network it should be on. The guest’s device needs the gateway to reach the internet; it has no legitimate reason to reach the laptop two seats over.

Lock the management plane away from users

The fastest way to turn a network incident into a network catastrophe is to leave the management interfaces reachable from the user segments. The admin pages for your switches, router, and access points are the keys to the building. They belong on their own VLAN, reachable only from an administrative network, never from the segment the public sits on.

This is cheap to do and painful to skip. If a hostile device on the guest VLAN can even see the switch’s login page, you’ve handed it a target it should never have been able to find. Management traffic and user traffic should not share a broadcast domain, full stop.

The convenience exceptions are designed, not accidental

Real networks have legitimate reasons for some cross-segment traffic — a shared cache server, a print service, a management host that needs to reach the fleet. The rule isn’t “never allow it.” The rule is that every one of those paths is an explicit, designed exception, not a side effect of flat networking.

So a shared service that the primary machines genuinely need lives on a trusted segment, with a specific firewall rule allowing exactly the traffic it requires and nothing more. The difference between a secure network and a fragile one is rarely whether exceptions exist; it’s whether each exception was a decision somebody made on purpose and can point to, versus a door that’s open because no one ever closed it.

Assume the LAN is the internet

Pulling it together, designing for a hostile public network is mostly the discipline of refusing the comfortable assumption. No trusted inside. Segment by trust. Isolate clients from each other. Wall off management. Make every cross-segment path an explicit exception. None of it is exotic — it’s the same defense-in-depth thinking that scales up to much bigger environments, just applied somewhere the threat is unusually honest about itself.

This is the muscle a lot of my earlier networking and consulting work leaned on, and it’s the same reason I keep insisting that security is architecture, not decoration — you can’t bolt isolation onto a flat network after the fact. When you genuinely can’t patch or trust the endpoints, the network becomes your control surface. If you’re standing up a guest or public network and want a sanity check on the segmentation, I’m easy to reach.