An OpenWrt secondary gateway can receive a client's IPv4 traffic and forward it to the existing main router through the same LAN connection. Keep the main router responsible for DHCP, change only one test client, and check the return path before trusting the arrangement for network policy.

Key Takeaways

A bridged switch port does not make a device a layer-three gateway.

Keep one DHCP server and an unused, fixed management address.

A single-arm path can have asymmetric replies and ICMP redirects.

Changing an IPv4 gateway does not redirect IPv6 automatically.

Recover a failed test by restoring the client's original gateway and DNS.

What can an OpenWrt secondary gateway control?

This guide covers OpenWrt 25.12 stable with fw4/nftables, one Ethernet connection to a trusted home LAN and one authorized test client. It follows official documentation and protocol behavior; no complete end-to-end device test was performed. There are no measured results or claims of enforcement reliability.［1］

Start with the self-hosting path and ownership checklist. A secondary gateway is useful for learning routing or implementing a deliberately designed service. If your task is simply changing a terminal's public exit, compare private-network control and an everyday internet exit before adding another router to maintain.

A single arm OpenWrt router receives and transmits routed packets on the same LAN device. The main router may return replies directly to the client, bypassing OpenWrt. Other LAN peers can also communicate directly. This topology is not a security boundary against a client selecting the original gateway, and is not automatically a transparent proxy or VPN.

Step 1: Draw the path and reserve a management address

Use the following example addressing, replacing it if your LAN differs. Before assigning anything, check the main router's leases, static reservations and existing devices for conflicts. A nonresponsive ping alone does not establish that an address is free.

Role	Example	Responsibility
Main router	`192.168.8.1/24`	Original internet gateway, DHCP and existing DNS service
OpenWrt	`192.168.8.2/24`	Fixed management address and test forwarding
Test client	`192.168.8.10/24`	Initially uses `.1`; later uses `.2` for IPv4
Management computer	Existing separate lease	Keeps `.1` as gateway and reaches `.2` directly

Outbound path: client → OpenWrt → main router → WAN. For ordinary IPv4 forwarding without source translation, the reply may be main router → client. Record both paths; a diagram with arrows in only one direction can hide the most relevant limitation.

Check the new-router preparation steps for address, firmware and administration basics. Keep a private backup of OpenWrt and record the main router's settings without modifying them. Confirm a wired local recovery method and the test client's original gateway, DNS, address mode and IPv6 state.

The same path works with a Debian machine instead of OpenWrt; the dae side gateway guide covers that implementation, its DNS and recovery.

Step 2: Configure OpenWrt while it is isolated

Do not connect a factory-default OpenWrt LAN to the live LAN before reviewing its DHCP and address settings. It may use the main router's address and advertise its own DHCP service. Connect only the management computer directly, keep a private backup and set the fixed unused address first.

In Network → Interfaces, edit the existing LAN interface. Keep its actual bridge or device assignment, choose a static IPv4 address, enter .2/24, and set the upstream IPv4 gateway to .1. Configure an approved reachable resolver for OpenWrt itself. Review and apply with LuCI's rollback protection; reconnect the computer in the new subnet when necessary.［2］

The fragment shows the relationship between fields, not a file to paste over the existing configuration. ACTUAL_LAN_DEVICE must match the device already configured for your ports. The DNS address below assumes the main router really provides DNS at .1.

config interface 'lan'
        option device 'ACTUAL_LAN_DEVICE'
        option proto 'static'
        option ipaddr '192.168.8.2'
        option netmask '255.255.255.0'
        option gateway '192.168.8.1'
        list dns '192.168.8.1'

On this secondary device, disable the LAN DHCPv4 server and set LAN RA, DHCPv6 and NDP proxy services to disabled for this exercise. In LuCI, check the LAN DHCP service's ignore setting as well as the IPv6 service settings. The main router remains their owner. Do not disable the main router's DHCP or copy a generic “dumb AP” recipe without checking which services it changes.［3］

Only then connect one reviewed LAN port to the main LAN. Do not also connect an unmanaged second cable, create a loop, or bridge the WAN port into LAN based on a guessed port name. DSA bridge membership describes layer-two connectivity; gateway addresses and routes belong to the logical interface.［4］

Step 3: Verify forwarding before switching one client

Open a fresh management session to .2 from the management computer. Confirm that the computer still uses .1 for internet access and has the expected DHCP server. If you lose access, use the local administration recovery checks rather than opening management on WAN.

Inspect OpenWrt's IPv4 route table: it needs the connected LAN route and a default route through .1 on the actual LAN device. A route is not a firewall permission. Review the effective LAN-zone forwarding policy and allow only the authorized test client's required IPv4 forwarding, including same-zone forwarding where needed. If an existing broad LAN policy already permits it, record that boundary rather than presenting this as isolated enforcement.［2］［5］

Keep input permissions for the existing trusted management network; never change all input or forward policies to ACCEPT to troubleshoot. If another firewall manager owns these rules, stop and have its owner implement the narrow permission. This guide does not install a proxy, tunnel or content-inspection service.

On the test client alone, keep its reserved address and subnet, then change the IPv4 gateway to .2. Preserve the original DNS initially so routing and resolution do not change at once. If the client requires manual addressing to override its gateway, record all original settings and ensure the chosen address is reserved outside conflicting leases. Do not change global DHCP gateway options or renew every household device.

How should secondary router DNS and return traffic work?

DNS is an independent decision. With .1 as resolver, the client reaches that same-subnet address directly and does not need .2 as a gateway. With .2 as resolver, OpenWrt must actually run a reachable DNS service and its upstream queries use OpenWrt's own routing. Neither choice proves that ordinary application traffic crossed the secondary gateway.［3］

Check method	Expected observation	Failure response
Inspect the client's address, gateway and DHCP server	Reserved client identity, gateway `.2`, DHCP still from main router	Restore the client settings and check for a second server
Inspect OpenWrt routes and generate a fresh client request	Outbound traffic enters OpenWrt and leaves toward `.1`	Check forwarding permissions and next-hop reachability
Inspect a bounded authorized flow's headers or counters	Return path is known, including direct replies	Do not claim symmetric inspection if replies bypass OpenWrt
Query a fresh name using the chosen DNS server	Query and upstream path match the chosen design	Restore DNS and check that the resolver service exists
Read client routes after repeated new requests	No unexpected redirect changes the effective next hop	Examine ICMP redirects and stop enforcement claims
Repeat checks with IPv6	Observed IPv6 path matches the separately defined design	Treat direct main-router IPv6 as a separate path

Linux can send ICMP redirects when a better next hop is on the same link. A client may then use .1 directly despite showing .2 as its configured gateway. Check the effective route and next hop, not only the saved gateway field. The kernel documents send_redirects and accept_redirects; any change to those controls must target the actual device and retain its previous value for rollback. Do not globally edit unrelated interfaces.［6］

Do not enable broad LAN masquerading to hide asymmetric replies. If mandatory policy needs symmetric traffic, stop and design a separate routed subnet/VLAN or reviewed, narrowly scoped source translation with its owner. Bridging cannot supply that guarantee.

Step 4: Check IPv6, power failure and recovery

The main router's IPv6 router advertisements can continue to give the client a direct IPv6 default route. Changing only its IPv4 gateway does not move that route. Follow the prefix-delegation and firewall procedure when building an actual downstream IPv6 network; do not enable a second RA server on the shared LAN as a shortcut.

From the test client, check the public exit address for the supported address families. In this initial forwarding design, the public IPv4 exit will normally remain the main router's WAN exit. That unchanged address is expected and does not prove that OpenWrt forwarded the outbound request; correlate it with route and forwarding evidence.

After the baseline works, disconnect power from only the authorized secondary device during a maintenance window. New client IPv4 requests through .2 should fail, while the management computer using .1 should retain its original path. DNS may also fail if it was moved to .2; IPv6 may continue directly. Those are expected distinctions to measure, not automatic fallback guarantees.

Recover by restoring the test client's gateway and DNS to their recorded original values, usually .1, or restoring its original DHCP mode. Create fresh requests and verify resolution, both address families and management access. If power restoration brings .2 back, repeat the original route, DNS and DHCP checks before using it again.

To retire the exercise, restore the client first, unplug the secondary device from the live LAN, then restore its earlier configuration locally. Only after isolation may its old DHCP/RA services be restored; never reintroduce a competing server into the live LAN. Remove only this exercise's firewall or sysctl changes, and compare saved baseline values. Preserve unrelated settings and confirm the main router and an unaffected client still work.

Summary

Reserve a unique management address and connect the secondary device only after disabling competing services.
Change one client's IPv4 gateway while keeping a separate management computer on the original path.
Verify DNS, asymmetric replies, redirects and IPv6 individually.
Restore the client before disconnecting or reconfiguring the secondary gateway.

FAQ

Is a secondary gateway the same as an access point?

No. An access point bridges frames, while a gateway must receive routed packets, select a next hop and have forwarding permission. Both roles can exist on one device but need separate checks.

Should both routers provide DHCP?

Keep the existing main router as the only DHCP server for this shared subnet. A second server may offer conflicting gateway or resolver information even if address pools do not overlap.

Why does the public IP stay unchanged?

This example forwards onward through the existing main router without adding another internet exit. Its WAN address normally remains visible; inspect the internal route to establish secondary forwarding.

Will every reply pass through OpenWrt?

Not necessarily. The main router can deliver replies directly to a client on the same subnet. Services needing symmetric traffic must use a topology or reviewed translation design that ensures it.

Can a client bypass the secondary gateway?

Yes. Same-subnet reachability, accepted redirects, a manually selected main gateway and direct IPv6 may provide other paths. Do not treat this topology as mandatory security enforcement.

Should I set DNS to the secondary address?

Only if a working authorized DNS service exists there and you intend to use it. Keep original DNS during the first routing test, then change and verify resolution as a separate step.

What should I change after a secondary-router power failure?

Restore only the test client's original gateway and DNS or its original DHCP mode. Avoid resetting the main router; it still owns the household's original connection and address service.

Sources:

OpenWrt — 25.12.0 release notes — https://openwrt.org/releases/25.12/notes-25.12.0
OpenWrt — Static routes — https://openwrt.org/docs/guide-user/network/routing/routes_configuration
OpenWrt — DHCP and DNS configuration — https://openwrt.org/docs/guide-user/base-system/dhcp ; odhcpd configuration reference — https://git.openwrt.org/project/odhcpd/plain/README.md
OpenWrt — Bridging all LAN ports — https://openwrt.org/docs/guide-user/network/dsa/dsa-common-config-1-bridging-all-lan-ports
OpenWrt — Firewall configuration — https://openwrt.org/docs/guide-user/firewall/firewall_configuration
Linux kernel — IP sysctl — https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html

Sources checked 11 October 2026.

Related Articles:

Use OpenWrt as a Secondary Gateway Without Losing Access