Pretty much all home routers already reject unsolicited connections from the internet, but that’s only half of a firewall’s job. Devices like Smart TVs, cameras, home appliances that talk to you, and guest devices are already inside your network and given way too much trust.

Whenever my router supports it, I apply three policies. Not to guard against outside threats, but against those originating within my network. Untrusted devices can’t reach the router or my trusted LAN. Private infrastructure stays blocked even through the WAN, and DNS requests can’t bypass my chosen resolver.

To demonstrate how these work, I used my edge network OpenWRT VM router, a Windows 11 VM acting as an IoT device, and a real Starlink internet connection to provide the WAN. Even with my supposedly internet-only network, the experiment exposed more than I expected.

Rule 1: My IoT network can use the internet, but nothing else

The first rule removes trust without breaking the services devices actually need

On my OpenWRT router, I built four separate networks:

The Windows 11 VM received 192.168.30.138, but creating a separate subnet for it wasn’t enough to isolate it. The IoT interface still belonged to OpenWRT’s trusted LAN firewall zone. As a result, the VM could still open LuCI through 192.168.30.254 and 192.168.25.254. It could also connect to a temporary listener on my physical laptop, proving it could jump subnets through the router.

I moved the IoT interface to a new IoT firewall zone, which I set Input to reject, Output to Accept, and Forward to reject.

• Input controls connections from IoT devices to OpenWRT itself.
• Output allows responses and traffic that originate from the router.
• Forward looks after traffic passing through it.

Lastly, I permitted forwarding from IoT to WAN, but not to LAN.

Rejecting input meant that services the VM genuinely needed, like DHCP and DNS, would also be blocked. To fix this, I added two exceptions under Network -> Firewall -> Traffic Rules:

1. Allow-DHCP-IoT: UDP from iot to Device (input) on port 67
2. Allow-DNS-IoT: TCP and UDP from iot to Device (input) on port 53

In OpenWRT, “Device (input)” means that requests are terminated on the router.

After saving and applying the changes, I confirmed that DHCP, router DNS, and web access were still working for the IoT network:

ipconfig /release
ipconfig /renew
nslookup example.com
curl.exe -I https://example.com

OpenWRT’s LuCI web interface and SSH are now unreachable from IoT, and a TCP connection to my laptop failed. My laptop on the trusted LAN could still reach LuCI normally.

Rule 2: I also block private addresses on the WAN side

Internet access should not include the equipment providing it

Isolating the IoT subnet from my trusted LAN was an obvious first choice for firewall rules. Unfortunately, however, it still left a less visible route open.

From the Windows VM, both of these tests still succeeded:

Test-NetConnection 192.168.91.2 -Port 53
Test-NetConnection 192.168.0.1 -Port 80

The first address belonged to my hypervisor’s NAT infrastructure. The second opened the management interface of my backup WAN USB modem. Essentially, I had allowed IoT traffic into the WAN zone, and both private destinations existed beyond that interface.

In my case, that’s a quirk of virtualization, but it can easily occur in any home network with double-NAT. “WAN” is just a description of an interface’s role. It doesn’t mean that every device beyond it has a public address. A compromised smart device could therefore probe upstream administration pages even if it doesn’t have access to the LAN.

I added a new traffic rule under Network -> Firewall -> Traffic Rules that rejects any protocol that originates from IoT, traveling toward WAN, targeting these IPv4 ranges:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16
• 100.64.0.0/10

The first three cover private IPv4 addresses. The last is a shared address space that’s used by my carrier’s CGNAT. I left both source addresses and ports unrestricted because the policy needs to apply to every IoT client and protocol.

After applying the rule, both connection tests failed, but the router-provided DNS and internet continued working. Now, traffic to a public website can still pass through a private gateway, but its packet carries the public server as its destination. Therefore, normal traffic never matches this rejection rule.

Rule 3: Hard-coded DNS addresses still lead back to my router

Devices can request Google or Cloudflare, but port 53 goes where I decide

My OpenWRT router tells clients which DNS resolver I’d like them to use, but that’s more of an offer rather than an order. A smart device or application can easily ignore it and send requests directly to a hard-coded address such as Google’s 8.8.8.8 or Cloudflare’s 1.1.1.1. That would mean IoT devices could bypass my local hostnames, filtering, logs, cache, and choice of upstream resolver.

I created a local OpenWRT hostname called firewall-test.proof and pointed it to 192.168.30.254. Querying OpenWRT from the Windows VM returned that address:

nslookup firewall-proof.test. 192.168.30.254

Google, on the other hand, knew nothing about my private hostname, so the control test behaved as expected:

nslookup firewall-proof.test. 8.8.8.8

It returned “Non-existent domain”.

Under Network -> Firewall -> Port Forwards, I created a rule named Intercept-DNS-IoT. I selected TCP and UDP, chose IoT as the source zone, and entered port 53 (DNS port) as the external port. The destination zone, internal address, and internal port were left unspecified to capture all IoT traffic. OpenWRT could then redirect matching requests to its own DNS service.

This isn’t technically a conventional filtering rule, but a NAT redirect, but the policy is still simple. DNS requests from the IoT network go through my router, regardless of the destination requested by the client.

To test, I repeated the exact query addressed to 8.8.8.8. This time it returned 192.168.30.254. Querying 1.1.1.1 produced the same result. nslookup still displayed the external address Windows had attempted to contact, but only OpenWRT could have provided my private hostname. That answer gave me the proof I needed that OpenWRT’s resolver had received the request.

These rules need more than a basic ISP router

The policies are portable, but the controls are not universal

I could have recommended disabling the WAN ICMP ping or UPnP, but that’s advice that most security-conscious readers already know. Blocking ping also contributes a lot less protection than its reputation suggests.

The really interesting and dangerous risks begin after a device joins your network.

The fair objection here is that OpenWRT exposes substantially more control than most ISP-supplied routers. Many basic, or even higher-end models provide automatic WAN filtering, port forwarding, UPnP, and the ability to block ping. But they can’t create firewall zones, filter traffic between networks, or redirect DNS.

There’s also still room for improvement. My redirect catches conventional DNS on TCP and UDP, but is helpless in stopping arbitrary DNS over HTTPS. I also made a mistake in selecting LAN as a destination zone and left my test VM temporarily without DHCP. A similar mistake could easily lock an administrator out.

I would therefore consider these three firewall policies, rather than literal entries in a configuration file. The same ideas carry across other capable routing platforms, like OPNsense, pfSense, IPFire, Firewalla, and UniFi. In saying that, on a simpler router, a guest network that blocks access to the local network could be the closest available substitute.

A home firewall should define trust within the network, not merely hide everything behind NAT. These three rules are my starting point whenever I encounter a router that supports them. If a router can’t even express one, that tells me more than I need to know about that router.