GL-MT6000 (Flint 2) – IP-Based Policy Routing (PBR) for WireGuard VPN

Router VPN, DNS, Leaks
1

Recently made the jump from an Netgear R9000 running DD-WRT to the GL-iNet GL-MT6000 (Flint 2). Overall, the experience has been very positive, but I’ve hit a hurdle with VPN policy routing.

My Setup & Use Case

  • I have a standalone PC that I regularly switch in and out of VPN traffic.

  • On DD-WRT, I handled this using NetSetMan to toggle between two pre-configured static IP addresses on the PC:

    • IP A: Bound to an IP-based VPN routing rule (routed through WireGuard).

    • IP B: Bypasses the VPN entirely (routed through regular WAN).

  • Toggling between these IPs in NetSetMan allowed me to seamlessly join or drop the VPN connection without logging into the router.

The Issue

  • The stock GL-iNet web interface handles Policy-Based Routing (PBR) by MAC address rather than source IP for client devices. Support confirmed this limitation.

  • As a temporary workaround, I configured NetSetMan to spoof MAC addresses instead of IPs. While this works, MAC spoofing is slower and a bit clunky compared to a simple IP swap.

What I've Tried So Far

  1. SSH: I attempted to set up custom routing rules via command line, but the underlying configuration got overly complex, so I backed out to avoid breaking anything.

  2. LuCI (Advanced OpenWrt UI): I looked into using standard OpenWrt options via LuCI, but the guides I found were written for older releases and didn't map cleanly to the Flint 2's current firmware.

Questions for the Community

  1. Has anyone successfully set up IP-based source routing on the GL-MT6000 while keeping the native WireGuard client active?

  2. Is there a clean way to configure this via LuCI (e.g., using luci-app-pbr) without breaking the default GL-iNet web UI features?

  3. Are there any lightweight nftables / iptables scripts or custom hotplug setups that fit this exact use case?

Any guides, config examples, or tips would be greatly appreciated!

3

Hi,

Thank you for the detailed explanation.

The native GL.iNet VPN Policy identifies specified devices by MAC address, so changing the IP address alone will normally not change the VPN route.
However, this can be achieved while keeping the native WireGuard client and GL.iNet Web UI active by adding one source-based IPv4 routing rule.

First, add the computer to the WireGuard tunnel under VPN Dashboard → Policy Mode → Specified Devices → All Targets.

image
image1449×547 48 KB

This makes traffic from the computer use WireGuard by default, regardless of which of the two IP addresses it is currently using.
Then, add an exception for the IP address that should use the normal WAN connection.
For example, if 192.168.1.20 should use WireGuard and 192.168.1.21 should use WAN, please run the following commands through SSH:

uci set network.ip_wan_bypass='rule'
uci set network.ip_wan_bypass.src='192.168.1.21/32'
uci set network.ip_wan_bypass.lookup='main'
uci set network.ip_wan_bypass.priority='1000'
uci commit network
/etc/init.d/network reload

After applying the rule, the expected routing behavior i

192.168.1.21 → Normal WAN
Other valid LAN IPs used by the same specified device → Existing WireGuard policy

Please note that this rule controls IPv4 routing only; IPv6 and DNS behavior may require separate configuration if they also need to follow different paths.

If you encounter any unexpected behavior during configuration or testing, please feel free to share the relevant details with us for further checking.
Thank you for your patience and understanding.

4

Thank you for the detailed explanation! Just to confirm: after following these steps, will I be able to use NetSetMan to switch between IPs—using 192.168.1.3 for the VPN and 192.168.1.9 for the normal WAN—so that whichever profile I select dictates the routing path?

Hopefully, in future updates, native IP-based policy routing will be supported alongside MAC addresses.

5

Hi,

Yes, after applying this configuration, you can use NetSetMan to switch between different IP profiles on the same device.

For example, with the following setup:

192.168.1.3 → follows the existing WireGuard policy  
192.168.1.9 → bypasses WireGuard and uses the normal WAN connection

The routing decision is based on the source IP address, while the device identification in the GL.iNet VPN Policy is still based on the MAC address.
Please make sure both NetSetMan profiles use the same physical MAC address. Do not enable MAC address randomization or MAC spoofing, otherwise the device may be recognized as a different client by the VPN Policy.

We have also recorded your suggestion about supporting native IP-based policy routing alongside MAC-based policies and submitted it to the relevant team for further evaluation.

Thank you again for your feedback and suggestion.

6

That worked. The only quirk is that on the clients list, it shows the WAN connection's IP address, but it's labeled as the VPN. Not sure if that will cause an issue if or when the VPN connection goes down with the kill switch, seeing as it thinks it's still on the VPN even though the IP has changed.

7

Hi,

Sorry for the delayed response.

We are glad to hear that the configuration is working as expected.
The behavior you noticed in the Client List is expected in this configuration. The VPN label in the Client List is based on the device’s MAC address and the GL.iNet VPN Policy configuration. Since this device is still assigned to the WireGuard policy by MAC address, the interface may continue to display it as a VPN client.

Regarding the Kill Switch behavior, this configuration keeps the device assigned to the WireGuard policy while creating a WAN routing exception for the specific IP address.
If you observe any unexpected behavior when the VPN connection is interrupted, please let us know and we will help check further.

Thank you again for your cooperation and understanding.