I wanted a remote work setup that stayed tidy without getting in the way. The useful bit is simple: VLANs by role, tight DHCP pools, sane remote access, and policies that stop the whole thing turning into a mess.
Start with VLANs that match roles, not desks. I use simple IDs: VLAN 10 for office staff (192.168.10.0/24), VLAN 20 for contractors and remote-access endpoints (192.168.20.0/24), VLAN 30 for IoT and printers (192.168.30.0/24), and VLAN 99 for guest Wi‑Fi (192.168.99.0/24). On the switch, tag access ports for the right VLAN and keep trunk ports to only the VLANs you actually need. The intent is straightforward: access ports in VLAN 10, trunks allowing 10,20,30,99, and a native VLAN 999 or no native VLAN at all.
For DHCP, use a separate server or the router’s DHCP for each VLAN. Keep the pools tight and the gateways fixed. For VLAN 10, use 192.168.10.10–192.168.10.200 with gateway 192.168.10.1 and a 24h lease for desk devices. For VLAN 20, use 192.168.20.50–192.168.20.150 with a 4h lease so stale entries clear out faster. Put static IPs for servers, printers, and network gear outside the pools. Use DHCP option 121 or static routes on the router for inter-VLAN services.
Policy belongs on the router or firewall, not scattered across switch ports. Set ACLs to allow only the traffic you need between VLANs. For example, allow VLAN 10 to reach VLAN 20 on TCP 22 and 443, but block VLAN 30 from reaching management. Use DHCP class-based options or DDNS to tag devices from specific subnets if your policy engine needs that. For remote access, I prefer WireGuard for a small, predictable tunnel, or a managed option such as Tailscale if you want less setup. If you use a traditional VPN, put the concentrator in VLAN 20 and hand remote clients internal addresses from that VLAN. Use split tunnelling when you want to keep office internet traffic down, and full tunnelling when all traffic needs inspection. Open only the port you need; WireGuard commonly uses UDP 51820. Add MFA at the VPN gateway and use short-lived certificates or keys for remote endpoints.
Policies turn a tidy network into something that keeps working. Write them down: what device state is acceptable, how often patching happens, and how remote access is requested and approved. Map those rules to your VLANs. Devices that meet policy get VLAN 10 access; unmanaged devices go to VLAN 99 with internet only. Set DHCP lease policy to match the device type, with longer leases for fixed desk gear and short leases for mobile or hotspot use. Keep an eye on the network with simple tools: Netflow or sFlow on the core switches, SNMP polling for interface errors, and a daily check of DHCP lease counts. When you change an ACL or add a VLAN, test isolation by trying to reach something that should be blocked and by checking the DHCP bindings. After creating VLAN 30, confirm a device there cannot ping the management IP on VLAN 1, then confirm a printer in VLAN 30 gets a lease in the right range.
After changes, ask a few remote staff to run normal tasks and note latency, VPN connection time, and any blocked services. Use that feedback to tighten or relax ACLs and adjust lease times. Keep change windows small and reversible. Push ACL rules in stages, keep backups of routing and DHCP configs, and script rollbacks. That is enough to keep remote access usable without letting the rest of the network wander off on its own.
