Brume 2 vpn policy is unreliable, even in the supported configuration. Have to restart VPN and toggle policy to allow IP's to connect

When the vpn client reconnects and ovpnclient-up script is called, it does not properly reconfigure vpnpolicy, so IP’s that should be routed out the WAN and not out the VPN tunnel stop connecting.

The fix is to add this line at the end of the ovpnclient-up script. This is on a nearly factory default brume 2 with only easytether added to the MWAN config

Pretty disappointed with the brume 2 software, It needs a clean build ASAP.

Can you post the code?

Hello, which policy mode are you using? could you give some screenshots of your settings?

Whoops, here is the script

service firewall stop;  service vpnpolicy stop;  service vpnpolicy-apply stop; service dnsmasq stop;service vpnpolicy start;service firewall start;service dnsmasq start;service vpnpolicy-apply start

The order of starting the services is important it seems to mirror the boot up order, so I stop them all and then start them as opposed to restarting.

I’m using VPN proxy mode 3, aka domain policy, to exclude a list of addresses from the tunnel.

Thank you for reporting this, just found route table 51 for the DNS query will be inconsistent under certain setups, trying to fix it now.

ip route show table 51
1 Like

Hi I figure out route table 51 issue is only related to wireguard client, not the case of OpenVPN.
I just tested tethering(not easytethering) and OpenVPN client, make reconnect happen by toggling server restart.
And the VPN policy works okay. I’m using firmware 4.2.0 beta2
Could you show how you do “easytether added to the MWAN config”?

The hack/fix i added isn’t so reliable, rebooting is the only solution, so I just added a “reboot” to the end of the ovpnclient-down for now. My connection has been useable ever since, but it’s frustrating to have several minutes of down time when the VPN fails occationally.

Here is my full mwan3 config, i use httping for easy tether since icmp does not work

config globals 'globals'
	option enabled '1'
	option mmx_mask '0x3F00'

config interface 'wan'
	option enabled '1'
	list track_ip '8.8.4.4'
	list track_ip '8.8.8.8'
	list track_ip '208.67.222.222'
	list track_ip '208.67.220.220'
	option family 'ipv4'
	option reliability '2'
	option count '1'
	option timeout '2'
	option interval '5'
	option down '3'
	option up '8'
	option initial_state 'offline'
	option track_method 'ping'
	option size '56'
	option max_ttl '60'
	option check_quality '0'
	option failure_interval '5'
	option recovery_interval '5'

config interface 'tethering'
	option enabled '1'
	list track_ip '8.8.4.4'
	list track_ip '8.8.8.8'
	list track_ip '208.67.222.222'
	list track_ip '208.67.220.220'
	option family 'ipv4'
	option reliability '2'
	option count '1'
	option timeout '2'
	option interval '5'
	option down '3'
	option up '8'
	option initial_state 'offline'
	option track_method 'ping'
	option size '56'
	option max_ttl '60'
	option check_quality '0'
	option failure_interval '5'
	option recovery_interval '5'

config member 'wan_only'
	option interface 'wan'
	option metric '1'
	option weight '3'

config member 'tethering_only'
	option interface 'tethering'
	option weight '3'
	option metric '2'

config member 'wan_balance'
	option interface 'wan'
	option metric '1'
	option weight '3'

config member 'tethering_balance'
	option interface 'tethering'
	option metric '1'
	option weight '3'

config policy 'default_poli'
	option last_resort 'default'
	list use_member 'wan_only'
	list use_member 'tethering_only'
	list use_member 'easytether_only'

config rule 'default_rule'
	option dest_ip '0.0.0.0/0'
	option use_policy 'default_poli'
	option family 'ipv4'

config interface 'wan6'
	option enabled '1'
	list track_ip '2001:4860:4860::8844'
	list track_ip '2001:4860:4860::8888'
	list track_ip '2620:0:ccd::2'
	list track_ip '2620:0:ccc::2'
	option family 'ipv6'
	option reliability '2'
	option count '1'
	option timeout '2'
	option interval '5'
	option down '3'
	option up '8'
	option initial_state 'offline'
	option track_method 'ping'
	option size '56'
	option max_ttl '60'
	option check_quality '0'
	option failure_interval '5'
	option recovery_interval '5'

config interface 'tethering6'
	option enabled '1'
	list track_ip '2001:4860:4860::8844'
	list track_ip '2001:4860:4860::8888'
	list track_ip '2620:0:ccd::2'
	list track_ip '2620:0:ccc::2'
	option family 'ipv6'
	option reliability '2'
	option count '1'
	option timeout '2'
	option interval '5'
	option down '3'
	option up '8'
	option initial_state 'offline'
	option track_method 'ping'
	option size '56'
	option max_ttl '60'
	option check_quality '0'
	option failure_interval '5'
	option recovery_interval '5'

config member 'wan6_only'
	option interface 'wan6'
	option metric '1'
	option weight '3'

config member 'tethering6_only'
	option interface 'tethering6'
	option weight '3'
	option metric '2'

config member 'wan6_balance'
	option interface 'wan6'
	option metric '1'
	option weight '3'

config member 'tethering6_balance'
	option interface 'tethering6'
	option metric '1'
	option weight '3'

config policy 'default_poli_v6'
	option last_resort 'default'
	list use_member 'wan6_only'
	list use_member 'tethering6_only'
	list use_member 'easytether6_only'

config rule 'default_rule_v6'
	option dest_ip '::/0'
	option family 'ipv6'
	option use_policy 'default_poli_v6'

config interface 'easytether'
	option family 'ipv4'
	list track_ip '1.1.1.1'
	list track_ip '1.0.0.1'
	list track_ip '8.8.8.8'
	list track_ip '8.8.4.4'
	option track_method 'httping'
	option httping_ssl '1'
	option reliability '2'
	option count '3'
	option timeout '2'
	option interval '3'
	option failure_interval '1'
	option down '2'
	option up '3'
	option enabled '1'
	option initial_state 'offline'
	option recovery_interval '1'
	option keep_failure_interval '1'

config member 'easytether_only'
	option interface 'easytether'
	option weight '3'
	option metric '3'

I can confirm the issue is resolved in the 4.2 beta

2 Likes

This is unfortunately not resolved, i have had to reboot again to reconnect to my excluded IP addreses. Needs a fix still

Thank you for the feedback, I’ll add the mwan3 config and test again asap.

I also factory reset and configured just to get it functional to test as well

I failed to setup easytethering. Could we start a TeamViewer session? Please send info to handongming#gl-inet.com.

Lets pause for now, its improved greatly

Original issue: after some hours, excluded ips wouldnt connect until reboot
Current status: working for days in a row without reboot. Im still seeing connectivity loss every few hours, but i cant yet determine if its a brume issue or cellular network.

Ill update if i can confirm the issue is not cellular related and we can troubleshoot via team viewer. I have zabbix monitoring connections to all my networks, so i just need to see if vpn internet is more consistent than excluded ips connections

2 Likes

Hello, Unfortunately this is still not working on a minimally configuration. I’m not too keen on using a remote session like team viewer, but I would be more open to using a chat like discord, matrix.im or similar? I’ve installed/reinstalled easy tether about 50 times, so I can explain well.

from a factory reset I complete the following steps

  1. install easytether ipk
  2. add network uci interface for easytether-tap as DHCP
  3. add mwan3 config
  4. add glinet openvpn configuration
  5. configure vpn policy
  6. set timezone and hostname
  7. optional: add my easytether hotplug script, just restarts easytether if it crashes
  8. reboot
  9. confirm mwan3 brings route up and vpn works. Also test vpn policy (traceroute to tunnel ip, traceroute to excluded ip)

Android setup

  1. enable developer options
  2. enable usb debugging
  3. ensure USB mode is set for Android Auto/etc…
  4. connect USB and accept debug authorization, set to remember device
  5. launch easy tether, and ensure usb is turned on. Should indicate “device connected”
  6. confirm that easytether-tap device is up in glinet brume: ip link

I think the version of httping in this old version of openwrt may be buggy, because I discovered that when the issue occurs, there is a hung httping process that can only be stopped with kill -9 signal.

When I killed this hung process, the addresses I’ve been having trouble with started responding. I’m trying to confirm this by running a scheduled task to kill httping periodically and will report back

Here is the fix/workaround

Add this line inside mwan.user within the existing disconnect action script

killall -9 httping

1 Like

Actually, the real issue is that on a cellular connection latency can be over 10seconds, so even though the VPN was able to remain connected over the default policy gateway, MWAN was frequently marking the interface down with even a 3 second timeout

I changed my mwan config to check every 30 seconds with a 10 second timeout. This has resolved the issue without any scripts needed.

1 Like

I need to re-open this, unfortunately. I’ve continued to have the issue even after changing the cellular mwan3 check to use localhost ping checks (no longer using httping)

I discovered that there is infact a packet routing issue while troubleshooting a connection to a new wireguard connection via my upstream router (on a linksys openwrt, not brume2)

after about 8 to 12 hours from the last reset the following occurs for all IP’s/domains in the exclusion:

Set far end router IP as VPN policy exclusion
packets are sent from my network, thru brume 2 which I captured in tcpdump
packets are seen in the Brume2 leaving towards the internet
The packets are seen on the other end, and reply packets are seen sent back to my local network in tcpdump
The reply packets are seen on the brume2 WAN interface via tcpdump (easytether)
the reply packets are not seen on the brume2 LAN interface

Once I restart the openvpn client on Brume2 AND toggle VPN policy to Global and then to exclude IPs, the connection is restored for ALL excluded IP’s in the VPN Policy No reboot is necessary, but both have to be restarted/toggled, the order doesn’t seem to matter.

Some additional observations: This does not effect IPs that have a persistent connection, it only effects new connections that hadn’t been made until after the 8-12 hours it works.

Could we start anydesk sesssion, please PM me.