/skill

Homelab Network Readiness

Use this skill before you change a home or small lab network. It is useful when the network has VLANs, local DNS, firewall rules, or remote VPN access.

This skill is for review and planning. Do not give router, firewall, DHCP, VLAN, or VPN commands until all of these facts are known:

• Exact device and software names
• Current network layout
• A tested rollback plan
• Local console access
• A set time for the work
• A person who can fix the network on site

If facts are missing, ask for them. Do not guess.

When to Use

Use this skill when the user wants to:

• Split one network into trusted, IoT, guest, server, or management VLANs.
• Move clients to Pi-hole, AdGuard Home, Unbound, or another local DNS service.
• Add WireGuard, Tailscale, ZeroTier, OpenVPN, or a router VPN.
• Check if a change could lock them out of a router, switch, access point, DNS server, or VPN server.
• Turn a rough network idea into a safe plan.
• Check security and speed before or after a change.

First Reply

The first reply must be read-only. It should include:

1. Missing facts to collect
2. Main risks
3. A plan made of small stages
4. Tests for each stage
5. A rollback plan

Do not give setup commands in the first reply.

Safety Rules

• Never expose router pages, DNS services, SSH, NAS pages, or VPN control pages to the public internet.
• Do not give commands until the exact platform and software version are known.
• Do not give commands until rollback steps are known.
• Require local console access before changes to management VLANs, trunk ports, default firewall rules, DHCP, or DNS.
• Keep one known working path to the router and internet.
• Test one client before moving a full network.
• Treat trusted, IoT, guest, camera, server, VPN, and management networks as separate trust zones.
• Do not change both DHCP and DNS at the same time unless rollback has been tested.
• Do not remove the old route, SSID, or DNS service until the new path works.
• Back up the current settings before making changes.
• Do not restart or reset network gear without clear user approval.

Required Inventory

Collect these facts before giving setup steps:

If the user cannot answer a key question, stop at a high-level plan.

VLAN and Trust-Zone Plan

Start with the goal. Do not start with vendor commands.

Before suggesting VLAN IDs or subnets, confirm:

1. The router can route and filter traffic between VLANs.
2. The switch supports the needed tagged and untagged traffic.
3. Each access point can map an SSID to a VLAN.
4. The user knows which port their admin device uses.
5. The management network will stay reachable.
6. No new subnet overlaps with a VPN or remote site.
7. IPv6 rules match the IPv4 rules.
8. Devices that need discovery can still work through a narrow rule or relay.

Discovery tools such as mDNS may be needed for printers, speakers, casting, and HomeKit. Do not open all traffic between zones just to make discovery work.

Unmanaged switches may drop or mix VLAN traffic. Treat their ports as one untagged network unless their behavior is known.

DNS Filtering Readiness

Treat Pi-hole or another local DNS service as a key dependency.

1. Give the DNS server a fixed or reserved address.
2. Confirm it can look up public names.
3. Confirm it can look up local home.arpa names.
4. Keep the old DNS service or a second local DNS server ready during the move.
5. Test one client or one VLAN first.
6. Record which networks may skip filtering and why.
7. Check both IPv4 and IPv6 DNS settings.
8. Check that clients are not using hard-coded DNS or encrypted DNS without approval.
9. Check that block rules do not break work VPNs, sign-in pages, updates, alarms, cameras, or health devices.
10. Make sure the user can still reach the DNS server by IP if name lookups fail.

A public DNS server used as a second client DNS choice may let clients skip filtering. Use it only as a short rollback aid and state this risk.

Useful proof includes:

Client gets the expected IP address
Client gets the expected gateway
Client gets the expected DNS server
Public name lookup works
Local home.arpa lookup works
The test name is blocked only on the planned networks
The router and DNS admin pages are blocked from guest and IoT networks
IPv4 and IPv6 follow the same access rules
A DNS failure does not block local recovery

Remote Access Readiness

Choose what the VPN may reach before making keys or opening ports.

Do not suggest port forwarding until all of these points are confirmed:

• The VPN server has current security fixes.
• The port points only to the VPN service.
• No admin page shares that public port.
• CGNAT and public IP behavior are known.
• Dynamic DNS needs are known.
• A lost peer key can be removed.
• Connection logs or status can show who connected.
• IPv6 exposure has been checked.
• The VPN does not use a subnet that overlaps with the remote network.
• The user has tested access from a real outside network, not only from home Wi-Fi.

Do not treat VPN users as fully trusted by default. Give each user or device only the access it needs.

Speed and Health Tests

Test before and after the change. Use the same client, server, place, and time when possible.

Check:

• Wired link speed and errors
• Wi-Fi signal and channel use
• Local transfer speed
• Internet download and upload speed
• Delay and packet loss
• DNS lookup time
• VPN speed and delay
• Router CPU and memory use during a test

Do not use only an internet speed test. It cannot show if a local VLAN, switch, or Wi-Fi link is slow.

A speed test can use a lot of data. Ask before running a long or repeated test on a metered link.

Change Sequence

Use small changes that are easy to undo:

1. Save the network map, IP plan, DHCP settings, DNS settings, VLAN settings, and firewall rules.
2. Record how to reach each device by IP.
3. Save a backup that can be restored.
4. Reserve addresses for the router, DNS server, controller, access points, NAS, and VPN server.
5. Create one new zone or VLAN without moving key devices.
6. Move one test client.
7. Test DHCP, DNS, local routes, internet access, IPv4, IPv6, and blocked traffic.
8. Add only the firewall rules that are needed.
9. Move one low-risk device group.
10. Watch logs, errors, and user reports.
11. Add VPN access with the smallest useful route and access rules.
12. Remove old paths only after the new setup has worked for the agreed test time.
13. Write down the final state, known limits, and rollback steps.

Pause after any failed test. Roll back before trying a new change.

Rollback Plan

A rollback plan must say:

• What event starts the rollback
• Who will do it
• How long to wait before rollback
• Which cable, port, SSID, IP, or console path will be used
• Which saved settings will be restored
• How to confirm that service is back
• What old service must stay online until the change is accepted

Examples of rollback triggers:

• The admin device cannot reach the router.
• The test client gets no address.
• DNS fails for more than five minutes.
• Cameras, alarms, or health devices stop working.
• Packet loss or delay goes above the agreed limit.
• Remote users lose the only way into the site.

Concrete Usage Example

User request:

I have an OPNsense router, a managed switch, two access points, and Pi-hole.
I want trusted, IoT, and guest VLANs. I also want WireGuard access to my NAS.

Good first reply:

Before setup steps, confirm the OPNsense version, switch model, access point
models, current subnet, port map, SSID map, Pi-hole address, NAS address, IPv6
state, and whether you have local console access.

Main risks:
1. A wrong trunk setting could cut off the access points.
2. Moving DHCP and DNS at once could leave clients with no network.
3. A broad WireGuard rule could expose all trusted devices.

Safe plan:
1. Back up all device settings and record the current port map.
2. Create the IoT VLAN without moving devices.
3. Put one test device on a test SSID.
4. Check its address, DNS, internet access, and blocked access to management.
5. Repeat for guest.
6. Move low-risk devices in small groups.
7. Add WireGuard with access to the NAS address and needed port only.
8. Test from a phone using mobile data.

Rollback:
Keep the old trusted SSID and Pi-hole settings active. If the test client or
admin computer loses access, move it back to the old SSID and restore the saved
switch or router settings.

Do not provide exact OPNsense, switch, or WireGuard commands until the missing facts and rollback steps are confirmed.

Review Checklist

• Each network has a clear reason to exist.
• Each trust zone has clear access rules.
• No management page is open to guest, IoT, or the public internet.
• The user can recover if DNS fails.
• DHCP changes were tested on one client.
• IPv4 and IPv6 rules match.
• VPN clients get only the routes and DNS settings they need.
• Firewall rules block traffic by default between zones.
• Each allow rule has a name and a reason.
• The user can reach the router, switch, access points, DNS server, and VPN server.
• Device discovery uses narrow rules.
• No subnet overlaps with a VPN or remote site.
• Wired, Wi-Fi, DNS, and VPN speed tests have before and after results.
• Rollback steps use the same words shown by the device UI or command tool.
• Old working paths remain until the new setup is accepted.

Common Mistakes

• Making VLANs before mapping switch ports and SSIDs.
• Moving the admin computer off the only management path.
• Changing DHCP and DNS for every client at once.
• Pointing all clients at Pi-hole before testing recovery.
• Opening a NAS, DNS server, router, or host manager to the internet.
• Giving VPN users full trusted-network access without a clear need.
• Adding a temporary allow-all rule and leaving it in place.
• Copying commands from a different device or software version.
• Testing only IPv4 while IPv6 stays open.
• Using a subnet that overlaps with a work VPN or remote home.
• Moving cameras, alarms, or health devices before low-risk devices.
• Removing the old SSID or DNS service too soon.
• Treating an unmanaged switch as if it supports VLANs.
• Using one failed speed test as proof of a network fault.

See Also

• Skill: homelab-network-setup
• Skill: network-config-validation
• Skill: network-interface-health