DEV Community: Denis Smoliakov

Policy Routing on a Home Router: Put Only the Traffic You Choose Behind a VPN

Denis Smoliakov — Wed, 02 Sep 2026 15:24:06 +0000

I wanted my whole home on a VPN — and within a week I wanted most of it off again. The TV stopped authenticating. The printer went unreachable. One service that checks client IPs decided my exit node was a datacenter and locked the account pending review. The classic fix — per-device VPN clients — works until you own fifteen devices that don't have one.

The answer I settled on: run the VPN on the router, but route by policy, not by default. Devices (or destinations) you choose go through the tunnel; everything else keeps the normal ISP path. This is the setup I run on an OpenWrt-based home router, and the lessons apply to any policy-routing-capable gateway.

The shape of the problem

A default-route VPN changes the egress for the entire LAN. That breaks:

devices that refuse to work from unfamiliar geolocations or datacenter IPs;
local-only services that assume the ISP network path;
anything your ISP filters differently when traffic arrives from its own CGNAT range versus a foreign exit.

What we want instead: two routing paths and a rule that picks between them per packet, based on the source device (or the destination).

Architecture in one paragraph

Bring the VPN tunnel up as its own interface on the router. Create a second routing table whose default route points into the tunnel. Then mark the packets you want tunneled (by source address, MAC-derived address, or destination) and add an ip rule that sends marked packets to the tunnel table. Unmarked packets follow the normal table. DNS needs the same split treatment or you'll leak.

Step 1 — The tunnel as its own interface

Whether it's WireGuard or a userspace client exposing a TUN device, the requirement is the same: the tunnel must be a first-class interface with its own default route in a separate table (say, table 100). Never make it the global default.

Step 2 — Mark the traffic you want tunneled

Firewall marks are the cleanest selector. Example: tunnel two specific devices by their LAN addresses:

# mark packets from the devices we choose
iptables -t mangle -A PREROUTING -s 192.168.1.30 -j MARK --set-mark 0x1
iptables -t mangle -A PREROUTING -s 192.168.1.31 -j MARK --set-mark 0x1

Prefer marking in PREROUTING by source so the mark is attached before the routing decision. If you need per-destination policy instead (e.g., "tunnel only traffic to these networks"), mark on destination — the mechanics are identical.

Step 3 — Policy route the marked packets

ip rule add fwmark 0x1 table 100

That single line is the entire trick: marked packets consult table 100 (tunnel default route); everything else stays on the ISP path. Add a matching rule for connection tracking so reply packets stay consistent, and you're routing.

Step 4 — Split DNS or you leak

Routing is only half of it. If every DNS query goes to the ISP resolver from the router's ISP address, your "private" devices are still identifiable, and split behavior becomes guesswork. Two sane options:

send tunneled devices' DNS to a resolver over the tunnel (DoT/DoH to a provider you trust), and keep the rest on the ISP resolver;
or run a local recursive resolver and steer it per client.

Either way, make the leak explicit and tested: resolve from a tunneled device and check the resolver's observed source.

Step 5 — Fail closed (or knowingly fail open)

Decide what happens when the tunnel drops:

Fail closed for the tunneled set: drop marked traffic when the tunnel is down. Safer for privacy-sensitive devices.
Fail open with a loud log for everything else, so the household doesn't lose the internet because a VPN provider had a bad minute.

Implement the decision once, deliberately. The worst failure mode is the silent one where a "tunneled" device quietly egresses via the ISP and nobody notices.

Gotchas I hit in the field

Hardware NAT bypasses your rules. Many home routers offload forwarding to a hardware engine that never sees your marks. If your policy routing "doesn't work", check whether HW NAT/fast path is enabled — disabling it costs some throughput and buys correctness.
MTU. Tunnel overhead plus a 1500 LAN MTU produces silent breakage on some sites. Clamp MSS on the tunnel path and test with large responses, not just pings.
CGNAT at the ISP. If your WAN address is in a shared range, inbound is dead anyway — which simplifies your threat model (nothing is exposed) but also means you can't easily verify from outside; test from the inside.
Firmware phones home. Consumer firmware with TR-069, auto-update, and cloud management will route around your intentions. Lock those down before you trust the box with policy decisions.
Test the boring path too. The most common regression is not VPN leakage — it's the non-tunneled half breaking because a rule was too broad. Verify that a device not in your marked set still resolves and browses normally.

Verification checklist

Tunneled device's public IP matches the VPN exit.
Untunneled device's public IP matches the ISP.
DNS for each group resolves from the expected source.
Kill the tunnel: tunneled devices either drop (fail closed) or visibly fail over — never silently leak.
Reboot the router: everything comes back in the right state without you touching it.

The payoff

You end up with a house where the default answer is "normal internet", and the VPN is a deliberate lane you assign to a device in one line of firewall config. Adding or removing a device from the tunnel is a one-liner, not a Saturday project.

If you've fought a router VPN setup before, I'm curious which part bit you — hardware NAT and DNS leaks are my top candidates.

Before You docker build: 7 Supply-Chain Checks for Third-Party Repos

Denis Smoliakov — Wed, 02 Sep 2026 15:20:49 +0000

You cloned a repo, read the README, and your fingers are already typing docker compose up. Stop. A third-party repository is untrusted input — and the build/run pipeline executes it. Most "it's just a demo repo" incidents I've audited started with a skipped two-minute review.

Here are seven checks, in the order that catches the most problems first. None takes more than a few minutes.

1. Read the Dockerfile line by line — especially RUN

The Dockerfile is the attack surface. Anything in a RUN instruction executes on your builder (and often inside your runtime):

RUN curl -s https://example.com/setup.sh | bash

curl | bash in a build is running an unaudited remote script with the builder's privileges. Watch for:

remote scripts piped to a shell (curl | sh, wget -qO- | bash);
downloads without checksum verification;
COPY --from= stages pulling from images you didn't expect;
ARG/ENV values that look like credentials or endpoints you didn't anticipate.

If the repo generates its Dockerfile from templates or config (some frameworks do), audit the generator too — injection into generated Dockerfiles is a real vulnerability class, not a theoretical one.

2. Check what the base image actually is

FROM python:latest

latest means "whatever the registry serves today" — a moving target. Prefer pinned tags, better a digest:

FROM python:3.12-slim@sha256:...

Quick sanity: does the base image match the project's claimed stack? A "minimal Redis wrapper" building from a full Node monolith image deserves a second look.

3. Audit the compose ports and volumes

services:
  db:
    ports:
      - "5432:5432"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Two classic mistakes:

Publishing ports to 0.0.0.0 that the README says are "internal". Bind to localhost (127.0.0.1:5432:5432) unless you truly need exposure.
Mounting the Docker socket into a container. That hands the container root-equivalent control of your host. If a demo needs it, run it on a throwaway VM — not your workstation.

Also scan volume mounts for sensitive host paths (~/.ssh, ~/.aws, /etc).

4. Look at the CI workflows before you trust the badges

.github/workflows/*.yml run in the project's CI, but a malicious or sloppy workflow can also be a clue about the project's security culture:

actions pinned by hash (actions/checkout@<sha>) vs floating tags (@v4);
workflows that post secrets to external endpoints;
pull_request_target workflows running untrusted code with write tokens.

And remember: green badges prove tests pass, not that the code is safe.

5. Grep the repo for secrets and surprises

Sixty seconds that pay for themselves:

# obvious secret patterns
grep -rnE "(api[_-]?key|secret|token|password)\s*[:=]\s*['\"][A-Za-z0-9_/+=-]{12,}" . --include='*' | grep -v test

# remote-exec patterns
grep -rnE "curl[^|]*\|\s*(bash|sh)|wget[^|]*\|\s*(bash|sh)" .

# docker socket references
grep -rn "docker.sock" .

A committed production key is a red flag about the maintainers; a postinstall script that phones home is a red flag about the software.

6. Pin and review dependencies you'll actually run

For images you'll run locally:

docker compose config        # what will actually run, with variables resolved

For package manifests, glance at the install hooks — postinstall/prepare scripts execute on install:

grep -A3 '"scripts"' package.json | grep -E 'postinstall|prepare|preinstall'

You don't need a full dependency audit for a weekend experiment. You need to know whether installing it runs code you haven't seen.

7. Run it like it's hostile

Last line of defense — isolation:

run unfamiliar stacks on a VM or a dedicated machine, not your daily driver;
use a separate browser profile/network for any UI it exposes;
don't paste real credentials into a demo you haven't reviewed;
keep the container runtime updated; consider --read-only filesystems and dropped capabilities for anything long-lived.

The two-minute habit

You won't do all seven every time. But checks 1, 3 and 5 catch the majority of real problems, and together they take about two minutes. Treat every third-party repo the way you treat a binary download from 2005: it doesn't get to run on your machine until you've decided it's allowed to.

What's the first thing you check in an unfamiliar repo? I'm collecting war stories — share yours in the comments.

Automatic HTTPS for Your Dockerized App with Caddy

Denis Smoliakov — Wed, 02 Sep 2026 15:18:11 +0000

Most "serve your app over HTTPS" tutorials still reach for Nginx plus certbot: hand-written reverse-proxy configs, a cron job for certificate renewal, and a debugging session for every acme-challenge failure. Caddy removes all of that. It obtains and renews TLS certificates automatically, and the entire setup fits in two lines of config.

In this tutorial you'll put a Dockerized application behind Caddy so that it's served over HTTPS with zero certificate management. No certbot, no renewal timers, no Nginx.

Prerequisites

A Linux server with Docker and Docker Compose installed (tested on Ubuntu 22.04+).
A domain name you control, with DNS access.
Ports 80 and 443 reachable from the internet (needed for the ACME HTTP-01 challenge).

Step 1 — Run your app on an internal port

You can use any containerized app. For this tutorial, a minimal example:

# docker-compose.yml
services:
  app:
    image: nginx:alpine   # stand-in for your real application

The important part: your app must be reachable from the Caddy container, not from the internet. Either don't publish its ports at all, or bind them to localhost only. Caddy will be the only service exposed publicly.

If your real app listens on port 3000, leave it unexposed:

services:
  app:
    image: your-app:latest
    # no `ports:` here — reachable only inside the compose network

Step 2 — Add Caddy to the stack

Add a caddy service to the same compose file:

services:
  app:
    image: your-app:latest

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"   # HTTP/3 (QUIC)
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config

volumes:
  caddy_data:
  caddy_config:

Two things matter here:

caddy_data persists TLS certificates across container rebuilds. Losing it forces re-issuance and counts against Let's Encrypt rate limits.
Port 443/udp enables HTTP/3; it's optional but costs nothing.

Now the Caddyfile. Create Caddyfile next to your compose file:

app.example.com {
    reverse_proxy app:3000
}

Replace app.example.com with your domain and app:3000 with your app's service name and port. That's the entire configuration. Caddy reads the site address, sees it's a real domain (not localhost), and automatically switches on TLS: it will solve the ACME HTTP-01 challenge, obtain the certificate from Let's Encrypt, store it in /data, and renew it in the background whenever it nears expiry.

Step 3 — Point DNS and open the firewall

Create an A record for your domain pointing at the server's public IP. If you run ufw, allow the web ports:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 443/udp

Step 4 — Start the stack and verify

docker compose up -d

Watch Caddy obtain the certificate on first run:

docker compose logs -f caddy

You should see lines like:

certificate obtained successfully
certificate stored in storage

Then verify from any machine:

curl -I https://app.example.com

Expect HTTP/2 200 (or HTTP/3 from a browser). Your app is now served with a valid, automatically-renewed certificate.

Useful variations

Parameterize the domain. Pass it through the environment instead of editing the Caddyfile:

{$DOMAIN} {
    reverse_proxy app:3000
}

  caddy:
    environment:
      DOMAIN: app.example.com

Test against staging. If you're iterating and don't want to burn Let's Encrypt rate limits, point Caddy at the staging CA while you experiment:

{
    acme_ca https://acme-staging-v02.api.letsencrypt.org/directory
}

app.example.com {
    reverse_proxy app:3000
}

Remove the acme_ca line for production.

Conclusion

Caddy turns "HTTPS for my container" from an ops project into two lines of config: one site block, one reverse_proxy. Certificates are issued on first start and renewed silently forever after, and the persistent /data volume keeps them safe across rebuilds. If you're starting a new Docker deployment, there's little reason to manage certificates by hand anymore.