That’s interesting @elorimer; I only tried to “access devices on the LAN behind the Asus” like you, but have not gone so far as to see what happened to internet traffic, I use it mainly to use Remote Desktop, so was just pleased (with the Auto-Detect solution from @hansome) to get as far as accessing devices behind the LAN, a major step forward for me.
If at some stage I want to implement what you have with Global Proxy enabled i.e. “…internet traffic … over the tunnel…” then this will not work for me at the present time, if for “devices behind the LAN”, only Auto-detect works…
In auto detect mode, the OpenVPN client command line option “–route-noexec” ignores the “redirect-gateway” option pushed by the server. The default gateway routes are handled by the “/etc/openvpn/scripts/ovpnclient-up” script in global proxy mode, but it is not handled in a good way in auto detect mode[bug].
As you advised, we will consider removing the “–route-noexec” option for the OpenVPN client to better respect the server pushed routes if there’s no other side effect.
To summarize the difference between global and auto mode:
Default route:
Global: VPN tunnel
Auto: Parse “wireguard.conf” file for “wgclient” and parse OpenVPN server push option for “ovpnclient”
Firewall LAN-WAN forward:
Global: Not allowed by default
Auto: Allowed by default
DNS:
Global: VPN DNS server
Auto: WAN DNS server
Therefore, auto mode is more advanced than global proxy. Global being the default mode should meet most use cases.
Very helpful, thanks. I guess it depends on how you write the up script, whether the routes are handled inside or outside the script. I’ll dig into it.
For both firewall and dns, these could still be changed in Auto?
I agree for most Global will be desired, as when you are at an insecure site. But when you are at a secure site, you may want to split-tunnel, depending on speeds. In the US, most homes are still served by asymmetric connections (cable companies seem to use 100/10, 25/1, etc). So sending internet traffic over the tunnel to a home openvpn server comes at a huge speed cost with no security benefit. Even where you have symmetric speeds, the home server may not take advantage of speeds over 200/200 because (i) home routers typically use tricks to accelerate processing that are disabled with the openvpn server active and (ii) just the encryption/decryption horsepower required with no real security benefit.
Deleting route-noexec makes the push/pull filter ignore work as expected.
I’m thinking the “auto detect” option should, comprehensively, return control over the connection to the server/client configurations for all possible configurations, without gl-inet intervention.
Is this supposed to work or not work with router in wifi repeater mode???
Remote is a Brume2. Direct wireguard connection from IOS works properly. But mobile data bandwidth is very low.
Rented apartment only has wifi. Wifi repeater work fine for internet. VPN wireguard client says it connects, but local wifi clients lose access to internet and have no access to remote LAN. IOS wireguard over wifi repeater also fails access to LAN.
Have played with all the settings mentioned here but they seem to make no difference.
Remote and Local just upgraded to latest firmware.