Vpn policy excluded addresses not working on brume 2

i have a list of IPs and domain names i do not want routed over the vpn and aftrr getting the router setup ive found thru traceroute they are all going over the nordvpn

can i please have some help troubleshooting why these arent routing over the internet directly?

Does this help?

thats the basic setup ive used but the new brume3 vpn is a little different.

for the more important ones i just made a static route, but for dns hostnames this isnt a reliable workaround.

Ahh sorry, don’t have Brume 2
:thinking:

thanks anyway.

i really dont want to factory reset this because i just spent a whole day getting it to replace my previous unifi router.

im hoping someone has a more targeted approach

So My brume 2’s are arriving today.

  1. What is the VPN global polices set to? Block Nonvpn traffic should not be enabled
  2. Are you adding the exclusion list of IP/Domain names in the GLUI(GL.iNet user interface) or is it in the VPN config file?

the problem with vpn policy on the new brume 2 is that when the vpn fails to connect, excluded ips and hosts do not bypass this like on previous devices from glinet

unfortunately the static route workaround doesnt work for tcp connections due to some firewall change i have yet to discover. even if tracert shows its working for icmp, the tcp packets arent getting routed back to the client or something so the connection just hangs

I but the bullet and backed up my custom config and factory reset.

I can confirm the vpn policy exclusions dont work. I thought that the feature to enforce vpn was just broken at first, but its clear that the excluded ips arent actually excluded from the tunnel or enforce vp n features

Looks like glinet needs to fix this on the new product

Can you just post a screenshot of your setting? It is much eaiser to understand.

Brume 2 is no different to other routers in this part.

Do you have the wireshark log still? Can you share?
What is the VPN provider?

Heres a screenshot of my vpn config attached

Heres traceroute
First is an example of where it should go, note there is another router upstream at 192.168.8.1. The brume has


no ip conflct with this device

Second is a traceroute of an ip that is not excluded from vpn which hits the von gateway as the first hop

Third is an ip that should route outside of the vpn tunnel but as you can see its first hop is the same as
Note this is an easy tether device, but shouldnt be an issue with the ping routing outside vpn

root@npancwangw01:~# traceroute -n -q 1 xx.xx.xx.xx
traceroute to 167.88.49.14 (167.88.49.14), 30 hops max, 46 byte packets
1 192.168.8.1 0.804 ms
2 *
3 *
4 *
5^C
root@npancwangw01:~# traceroute -n 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets
1 10.8.0.1 90.569 ms 85.569 ms 72.215 ms
2 193.29.61.3 66.380 ms 71.915 ms 93.420 ms
3 72.29.198.69 78.291 ms 83.323 ms 73.736 ms
4 208.116.131.82 72.996 ms 68.543 ms 65.687 ms
5 172.71.144.3 90.254 ms 172.71.148.3 68.787 ms 108.162.243.11 118.057 ms
6 1.1.1.1 73.409 ms 67.000 ms 80.629 ms
root@npancwangw01:~# traceroute -n 192.168.117.1
traceroute to 192.168.117.1 (192.168.117.1), 30 hops max, 46 byte packets
1 10.8.0.1 69.062 ms 64.088 ms 70.522 ms
2 * * *

Are you doing traceroute on the router?

Can you do on the client that is connected to the router?

Also can you give some info about the vpn? e.g. wireguard or ovpn? Basic config info?

The vpn is just a default nordvpn open configuration.

The tests need to be from the router because the most important configuration is another luci configured wireguard vpn that routes a unique subnet. This can’t be routed over the nord vpn tunnel.

But here is a trace route to an excluded vpn on a client

No more input? I’m kind of frustrated because i bought the brume 2 on the success of the mango i had before

I think your VPN Provider might have a kill swich bult into the config file. I don’t think you can use the GUI VPN policy need to do it in openwrt:

In my tests on Brume 2 running Firmware 4.1.1-1105, VPN policy exclusions are working. Domain names/IP addresses that are on the exclusion list go directly out to my ISP, while other names/IP addresses go through the NordVPN tunnel. I used tracert on a WIndows 10 client PC. The GL.iNet “Kill Switch” has not been enabled.

Maybe the LuCI-configured VPN interferes with the Admin Panel-configured VPN. Can you test with no LuCI-configured VPN?

I do not work for and I do not have formal association with GL.iNet

I tested again using traceroute in SSH on the Brume 2. VPN policy exclusions are not working, with all domain names/IP addresses going through the NordVPN tunnel.

It looks like VPN policy works on traffic from a client device connected to the router, but not on traffic from within the router itself.

Hmm, is this only from the default lan network? I have disabled it and setup my network on vlans, which could be related to your discovery.

This is pretty disappointing that the policy is configured like this.

I looked at the glinet scripts that handle the vpn policy and they only take a network on LAN and Guest network into account. So ive moved all of my config to luci for nordvpn

It seems the reason i didnt have any issues before is because i had an upstream router before, and now that ive consolidated my vlan routing and wan connectivity into the brume two, im discovering the limitations of the glinet customizations.

The brume2 is great hardware limited by the hard coded glinet software. Hopefully a “clean” build of openwrt will become available for the brume 2 so i can run this without ripping out the custom scripts.

As of now, this is working configured with luci and the vpn policy addon. Im also workjng on a script that will change the gateway for vpn policy exclusions and the static route for mwan failover between ethernet and easytether.

gl-infra-builder to the rescue! I’ve got a clean build running right now. It includes the proprietary driver stack, but other than that you can pretty much do anything you’d normally do with a stock build. I can share what I’ve got if you’re interested, or you certainly seem competent enough to build your own.

2 Likes