After moving the Internet connection from the FRITZ!Box to the Flint 2, the basic network was finally where I wanted it.
The FRITZ!Box handles the DSL line and PPPoE passthrough. The Flint establishes the Internet connection and acts as the router for everything at home.
There was still one part I wanted to simplify: IPv6 on the home network.
My 1&1 connection needs IPv6. IPv4 is provided through DS-Lite, so I cannot simply disable IPv6 on the router. But that does not mean every device on the LAN also needs IPv6.
For my use case, it was simpler to keep IPv6 on the WAN side of the Flint while making the client-facing LAN IPv4-only:
ISP
│
│ Native IPv6 + DS-Lite
▼
Router
│
│ IPv4 only
▼
Home networkThat also makes the VPN setup easier to reason about.
Why I did not disable IPv6 completely
On this connection, the Flint receives native IPv6 and uses it for the DS-Lite tunnel that provides IPv4 connectivity:
Native IPv6
│
▼
Router
│
└── DS-Lite tunnel → IPv4 InternetTurning off Network → IPv6 in the GL.iNet interface would therefore break the wrong part of the setup. The router itself still needs IPv6.
Instead, I stopped the Flint from assigning part of the delegated IPv6 prefix to the LAN and advertising it to clients.
Why I wanted an IPv4-only LAN
With IPv6 enabled on the LAN, a device can have two independent paths to the Internet:
IPv4 → VPN
IPv6 → ?A correctly configured dual-stack VPN can handle both. I just do not currently have a reason to provide native IPv6 Internet access to my laptops, phones, TVs, or other home devices.
Keeping the clients IPv4-only gives me one path to check and one set of VPN rules to maintain:
LAN devices → IPv4 onlyThe Flint can still use IPv6 on its WAN side for the 1&1 connection and DS-Lite. This is not an attempt to remove IPv6 from the entire network; it only separates what the WAN requires from what I expose to clients.
Disabling IPv6 on the LAN only
The existing OpenWrt configuration assigned a prefix to the LAN and enabled DHCPv6 and router advertisements:
network.lan.ip6assign='60'
dhcp.lan.dhcpv6='server'
dhcp.lan.ra='server'
dhcp.lan.ra_slaac='1'I changed those settings over SSH:
uci delete network.lan.ip6assign
uci set dhcp.lan.dhcpv6='disabled'
uci set dhcp.lan.ra='disabled'
uci set dhcp.lan.ra_slaac='0'
uci commit network
uci commit dhcp
/etc/init.d/network restartA LAN machine still received its normal private IPv4 address, but no longer received a globally routable IPv6 address. It still had an address similar to:
fe80::...That is expected. IPv6 link-local addresses remain available on the local link and are not routed across the Internet.
I then checked both paths:
ping -4 -c 3 1.1.1.1
ping -6 -c 3 2606:4700:4700::1111The IPv4 test worked, while the IPv6 test returned Network is unreachable.
At the same time, the dynamic DS-Lite interface on the Flint remained up:
wan6_4
proto: dslite
up: trueIPv6 had disappeared only from the client-facing side. When checking or documenting this, there is no need to publish public IPv6 addresses or delegated prefixes. The useful information is whether the WAN and DS-Lite interfaces are up.
OpenWrt’s IPv6 configuration documentation describes ip6assign as the prefix length assigned to a downstream interface. Removing it, together with disabling DHCPv6 and router advertisements, is the important distinction here: the upstream IPv6 connection stays intact.
The VPN layout I wanted
I wanted two VPN tunnels, both using German endpoints.
The first is reserved for one dedicated device. The second is the default for practically everything else. One excluded device is the only exception and uses the regular Internet connection without the router VPN.
Router
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Dedicated device Other devices Excluded device
│ │ │
▼ ▼ ▼
VPN Tunnel 1 VPN Tunnel 2 Direct WANBoth VPNs happen to exit in Germany, but keeping the dedicated device in a separate tunnel still has a practical advantage. I can reconnect, replace, or troubleshoot its VPN without interrupting the tunnel used by everything else. It also gives that device its own kill switch, so a tunnel failure cannot silently move its traffic onto the regular WAN.
Tunnel 1: the dedicated device
Tunnel 1 has the highest priority.
Its source is set to Specified Devices and contains only the dedicated device. Its destination is All Targets.
Dedicated device
│
▼
VPN Tunnel 1Traffic from the dedicated device matches this rule immediately. Other devices do not, so the Flint continues to the next tunnel rule.
Tunnel 2: the default route
For Tunnel 2, I did not want to maintain an ever-growing list of ordinary devices. I set its source to Exclude Specified Devices and excluded only the device that should use the direct connection. Its destination is again All Targets.
Because Tunnel 1 has higher priority, it catches the dedicated device first. Almost everything else falls into Tunnel 2:
Existing devices
Guest devices
New devices
│
▼
VPN Tunnel 2This gives me the default I wanted. If a new device joins the network tomorrow, there is nothing else to configure. It is not the excluded device, so it automatically matches Tunnel 2.
GL.iNet’s VPN Dashboard documentation confirms that Policy Mode can identify specified or excluded devices by MAC address and evaluates tunnel rules in priority order.
Keeping one device outside the VPN
The excluded device does not belong to either tunnel. It therefore reaches All Other Traffic, which I set to Allow Non-VPN Traffic:
Excluded device
│
▼
Router
│
▼
Direct WANI keep this device on the regular connection deliberately.
The kill switches matter
The routing rules decide which VPN a device should use. The kill switches decide what happens when that VPN is unavailable.
I enabled the individual Kill Switch for both tunnels. If Tunnel 1 fails, the dedicated device loses Internet access. If Tunnel 2 fails, all the ordinary devices assigned to it lose Internet access.
Device assigned to VPN
│
▼
VPN unavailable
│
X
No InternetThey do not quietly fall back to the regular WAN connection. GL.iNet documents this as the behavior of a tunnel-specific kill switch: matching traffic is blocked when that tunnel fails instead of falling through to the normal WAN.
The excluded device behaves differently because it was never assigned to either VPN tunnel. Its direct route remains intentional.
Why I leave the Enhanced Kill Switch off
GL.iNet also provides an Enhanced Kill Switch under All Other Traffic. I leave that disabled.
The Enhanced Kill Switch blocks anything that does not match a VPN tunnel. In this setup, that would also block the excluded device—the one device I deliberately want outside the router VPN.
My settings are therefore:
Tunnel 1 Kill Switch ON
Tunnel 2 Kill Switch ON
Allow Non-VPN Traffic ON
Enhanced Kill Switch OFFThis sounds contradictory at first, but the two levels apply to different traffic. Anything assigned to a VPN is protected by that tunnel’s kill switch. Only genuinely unmatched traffic is allowed to use the WAN, and the excluded device is intentionally the one that ends up there.
The final setup
The complete network now looks like this:
ISP / DSL
│
DSL front-end
│
PPPoE passthrough
│
Router
│
IPv4-only client LAN
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Dedicated device Other devices Excluded device
│ │ │
▼ ▼ ▼
VPN Tunnel 1 VPN Tunnel 2 Direct WANNew devices naturally join the middle path:
New device
│
▼
Matches Tunnel 1? No
│
▼
Excluded from Tunnel 2? No
│
▼
VPN Tunnel 2The part I like most is not really the VPN itself. It is that the routing is now predictable.
The Flint retains the IPv6 functionality it needs for the ISP connection and DS-Lite, while clients get a simpler IPv4-only view of the Internet. The dedicated device has its own VPN connection, ordinary and newly joined devices use another VPN by default, and the excluded device is the one deliberate exception.
That is much easier for me to understand than IPv4 routes, IPv6 routes, VPN exceptions, and fallback paths all operating at the same time.
A useful fallback
Keeping the FRITZ!Box’s own 1&1 connection active also gives me a simple emergency fallback.
If something goes wrong with the Flint, or I need Internet access while troubleshooting it, I can connect a device directly to the FRITZ!Box. That device then uses the FRITZ!Box’s normal 1&1 connection without any of the VPN routing or tunnel policies on the Flint.