Networking / Isolation

A VLAN With No Internet Does Not Confine the App on Your Own PC

A 3D printer running an end-of-life operating system is a good candidate for a network of its own with no way out. That part went fine, at three independent layers. Then the vendor's slicer, running on the workstation, popped an update prompt and loaded a web page. The isolation was correct and the application was never inside it.

Three layers for the device, and use all three

For the appliance itself, defence in depth is cheap here, and each layer fails differently:

The network-level internet toggle. UniFi has a per-network setting that is separate from any firewall policy. It survives someone reorganising rules later.
An explicit block to the WAN zone. Scope this one to all connection states, not just new and invalid. Inter-VLAN rules need the narrower scope so return traffic for sessions you initiate keeps working, but nothing should ever establish a path to the internet in either direction.
No default route on the interface itself. The host-side layer, and the one that holds even if somebody edits the firewall. Configure the address with no gateway, and set the interface to never take a default route:
```
# NetworkManager
ipv4.never-default yes
ipv6.never-default yes

# netplan, for a DHCP interface on that VLAN
dhcp4-overrides: { use-routes: false, use-dns: false }
```

The result you want is an interface whose entire routing table is the local subnet and nothing else.

BE WARNED: a second NIC with its own default route is a silent failover path. Before this work, the workstation's spare interface sat on another VLAN with a gateway. If the primary link had dropped, every browser and game on that machine would have quietly failed over onto the wrong network. Check ip route on any multi-homed host and confirm exactly one default route exists.

The bug: isolation controls the subnet, not the process

Here is the part that is easy to get wrong, and it is worth stating plainly.

Putting a NIC on an isolated VLAN controls what is reachable on that subnet. It does nothing to the application. A normal unsandboxed process reads the whole routing table, so anything it sends that is not addressed to the isolated subnet, an update check, telemetry, a documentation link, simply leaves by the interface that does have internet, exactly like every other program on the machine.

ip route
# default via 192.168.1.1 dev enp17s0        <-- the slicer's update check went here
# 192.168.9.0/24 dev enp18s0 scope link      <-- only printer-addressed traffic

So the network work was right, and it answered a different question than the one being asked. Isolating the device is a network problem. Confining the application is a host problem.

Confining the application: a network namespace

Move the interface into its own network namespace and start the app inside it. Once moved, the interface no longer exists in the root namespace, and the namespace contains no interface capable of reaching anything else:

ip netns add printer
ip link set enp18s0 netns printer
ip -n printer addr add 192.0.2.15/24 dev enp18s0
ip -n printer link set enp18s0 up          # no default route, deliberately

# launch the app inside it
ip netns exec printer runuser -u you -- /usr/bin/TheSlicer

Four details that turn that into something that survives a reboot:

Tell your network manager to stop touching the interface, or it will fight the move. In NetworkManager that is unmanaged-devices=interface-name:enp18s0 in a drop-in.
Wait for the link after the move. The interface reports carrier a couple of seconds late following a namespace move, so a setup script needs a short retry loop rather than one attempt.
Scope the sudo rule to the exact wrapper path. A blanket ip netns exec grant is root-equivalent, because you can exec anything with it. Grant the one script, and keep the display variables with env_keep.
Override the desktop entry at user level. A file in ~/.local/share/applications beats the packaged one, so the launcher survives package upgrades.

The GUI is unaffected, because only the network namespace changes. Mount and IPC namespaces are shared, so the display socket still works.

Now you cannot monitor or back the device up either

Isolation that works cuts off your own tooling, and it is better to plan that than to discover it. Our monitoring and backup servers sit on the main VLAN and can no longer reach the printer at all.

Route both through the one host that has a foot in both networks:

Backups over SSH with a jump host, using ProxyJump, so the backup server never needs a path of its own.
Monitoring as an agent-over-SSH data source, where the bridge host runs the agent command remotely and returns the output, instead of the monitoring server connecting directly.
Time from the bridge host. An isolated VLAN's gateway serves no NTP, and a device with a wrong clock produces certificate errors and confusing logs. Run chrony on the bridge and point the device at it.

When this isn't your problem

The device's software is not on your daily-driver machine. Then the network layers are enough, and there is no application to confine.
The app is already a Flatpak or a container. You have a sandbox already. Remove its network access rather than building a namespace by hand.
You want the vendor software to have internet. Fine, and worth deciding on purpose rather than discovering. It is the difference between blocking the device and blocking the vendor.