Skip to content

Home Network Architecture with RouterOS, OpenWrt, SmartDNS, and FRP

This article records a practical home network architecture built around MikroTik RouterOS, an OpenWrt bypass router, SmartDNS, Tailscale, and FRP. It is not a copy-and-paste configuration guide. It is more about ownership: which device should own routing, DNS, proxy, IPv6, public services, and recovery.

Design Goal

The goal is to keep the network understandable after it grows beyond a simple router:

  • RouterOS stays the primary router and policy owner.
  • OpenWrt stays the proxy and Tailscale owner.
  • SmartDNS gives the LAN a stable DNS entry point.
  • Containers on RouterOS reduce hard coupling to the bypass router.
  • FRP exposes selected internal services through VPS nodes.
  • Every change must have a rollback path.

Topology

Internet / IPv6 PD / FRP VPS
        |
        v
MikroTik RouterOS
Primary router / DHCP / DNS entry / IPv6 owner / firewall / QoS / containers
        |
        +-- SmartDNS container
        |   Main LAN DNS service
        |
        +-- Xray container
        |   Proxy backend for selected SmartDNS upstreams
        |
        +-- FRPC container
        |   Connects to remote frps servers and publishes selected services
        |
        +-- OpenWrt bypass router
        |   Passwall, fine-grained proxy policy, Tailscale subnet router and exit node
        |
        +-- NAS
            Storage, applications, downloads, and selected public IPv6 services

Ownership Model

The most important decision is to avoid split ownership. When two devices both believe they own the same function, troubleshooting becomes slow and recovery becomes fragile.

Area Owner Reason
LAN gateway RouterOS It is the physical edge router and the most stable place for DHCP, firewall, IPv6 RA, and QoS.
IPv4 coarse routing RouterOS Address lists and mangle counters are easier to audit at the main router.
Proxy classification OpenWrt Passwall is better suited for application and domain-level proxy decisions.
DNS entry SmartDNS on RouterOS LAN clients get one stable DNS endpoint even if upstream logic changes.
DNS proxy backend RouterOS Xray first, OpenWrt fallback This reduces the dependency between DNS resolution and the bypass router.
Remote management Tailscale first Management should not depend on FRP public service tunnels.
Public service tunnel FRP FRP is useful for selected HTTP/HTTPS services behind NAT or changing addresses.

Traffic Paths

Normal LAN Traffic

Most LAN traffic goes directly through RouterOS. RouterOS owns NAT, firewall, IPv6, and QoS. This keeps the default path simple and predictable.

Proxy Devices

Selected devices are placed into a proxy-device list. RouterOS performs coarse routing: domestic or direct destinations stay direct, while non-direct IPv4 traffic can be sent to the OpenWrt bypass router. OpenWrt then performs fine-grained policy decisions through Passwall.

This keeps the main router responsible for the “where should traffic go first?” question, while OpenWrt answers the “which proxy rule should this flow match?” question.

DNS

LAN clients use SmartDNS as the main DNS service. SmartDNS uses domain sets and upstream groups to separate direct, domestic, overseas, and special domains.

The important improvement is to give SmartDNS a proxy backend on RouterOS itself. If the bypass router is down, DNS can still fall back cleanly instead of making every DNS decision depend on OpenWrt.

IPv6

RouterOS owns IPv6 prefix delegation, LAN advertisement, DHCPv6 behavior, and firewall forwarding. Public IPv6 services should be explicitly minimized. For hosts such as a NAS, a stable IPv6 token is easier to reason about than relying only on DDNS updates.

FRP Public Services

FRPC runs as a RouterOS container and connects to remote frps servers on VPS nodes. Only selected services are exposed. The production FRPC container is upgraded through canary testing first, while the previous container image is kept as a short-term rollback point.

Observability

Interface traffic graphs are helpful, but they are not proof of correct routing. For example, similar TX/RX curves on a bypass router do not automatically mean direct traffic is being proxied.

Better evidence comes from paired counters:

  • RouterOS mangle counters before and after a test window.
  • OpenWrt nftables or Passwall counters during the same window.
  • SmartDNS query samples for DNS attribution.
  • Tailscale interface counters when testing subnet routing or exit-node paths.

The useful habit is to test one traffic class at a time: domestic IPv4, overseas IPv4, IPv6 direct, DNS proxy upstream, Tailscale, and high-connection P2P traffic.

Fallback Strategy

Every stage should have a fallback before it starts:

  • Keep LAN or Tailscale management working.
  • Change one device and one function at a time.
  • Export RouterOS configuration before risky changes.
  • Keep OpenWrt sysupgrade backups for network changes.
  • Use canary containers before replacing production containers.
  • Keep only the latest useful backups, plus failed or rollback evidence.

This is not just tidiness. A smaller recovery surface makes the network less frightening to operate.

Phase Dependency

The architecture was refined in phases:

Inventory and documentation
    -> Management security
    -> Maintenance and recovery
        -> IPv6 public service boundary
            -> DNS, DDNS, and automation
                -> Proxy, QoS, containers, and observability
                    -> Routing and traffic splitting
                        -> Bypass observability

Management security + recovery + container health
    -> FRP edge tunnel upgrade

This order matters. It is tempting to start with the flashy pieces, such as proxy rules or tunnels, but the quiet foundation is what makes later changes safe.

Lessons Learned

  • The main router should own the default path.
  • The bypass router should own proxy intelligence, not the whole network.
  • DNS deserves its own fallback design.
  • IPv6 public services need a strict allowlist mindset.
  • Remote access should not depend on the public-service tunnel it is used to repair.
  • Configuration documents are part of the system, not an afterthought.

The end result is a home network that is still a living lab, but no longer feels like a pile of clever one-off fixes. It has layers, owners, and rollback points.