Thanks for getting back to me, I’ll try to test it at work tomorrow, where the WiFi is. No way to test at home as I’m inside the LAN?
If you can ssh into Beryl AX terminal, it will be okay.
I have a terminal App on my iPhone which I use to SSH so I will use that and post the results tomorrow.
Hi
Well not much happend TBH. This is it. I waited 5 minutes it just gets stuck. No reply.
Ctrl-C says 100% packet loss.
All profile details shown in the above configs, although pls note I have added 0.0.0.0/0 to the Allowed IPs in the Peer Profile (not shown above). My Beryl AX is now on 192.168.7.1 (to avoid Huawei 192.168.8.1 Modems).
Anything else I can check?
Actually, you should ping 10.6.0.1 in your setup. But that’s okay. I think I’ve found the problem.
Please try to disable “IP masquerading” in the VPN dashboard setting.
192.168.9.0/24 is your VPN server site network, right?
- Noted on 10.6.0.1. I tried that and no change to the ping result. See here:
- I tried disabling “IP masquerading” in the WG VPN dashboard setting. No change.
In fact I tried various combinations of “IP masquerading” and “Allow Remote Access LAN”.
I also tried this on the OpenVPN profile (which is also not workign as a Client Profile in the AX Router); also no go.
I also tried various combinations of the GLOBAL Options. No go.
I would note that it is pretty confusing that SOME of the VPN Options available in the Web Admin Panel are nto available in the App.
- Yes 192.168.9.0/24 is my VPN Server network (ASUS RT-AX86U), but I don’t think the issue lies with the Server. I can via Wifi or LTE use the Wireguard and OpenVPN iOS Apps and succesfiully connect each time. For the Wireguard App the ONLY change to the profile given to by my ASUS VPN Server was that I had to add 192.168.9.0/24 to the Allowed IPs in the WG App Client config as shown here:
This is a really frustrating setup issue, surely it cannot be this hard. I simply cannot fathom that what works via a WG App to my home router cannot work trying to use the Beryl AX as a WG (or indeed OpenVPN) Client using the same VPN profiles. I can even get through to my ASUS Network via VPN using the iOS APP, with my phone connected to the Beryl in repeater mode (but not as a VPN Client).
k.
Sorry that this issue frustrating you for so long. It’s my first time learning about this use case so I’m not familiar with it. After check more about your config I found it Allowed IPs related issue.
The right setup step is to change to “Auto Detect” mode:
It’s indeed sort of complicated, as to meet the needs of different user scenarios. We’ll try to improve that.
Regards.
3 Likes
Oh my goodness, you’re an absolute star hansome!
Thank you for your patience! I have no idea what that “Auto Detect” Mode does, but together with “IP masquerading” ON (not off as above), BOTH the OpenVPN and the WG profiles work.
Absolutely fabulous. I am not sure what MTU should be because there is a glitch (separate thread, see here) where it gets stuck on 0, so for now I just put in 1280 (see point #2 in that thread).
Please, please put this in the Docs (I can see that Auto Detect means the Profile uses the Config Files Routing Rules).
Happy Days…
k.
1 Like
One request please; if not already in there, could you put this selection from the default Global Proxy to Auto Detect in the App? I couldn’t see it but I may have missed it.
As you suggested, I tested Global Proxy and Auto Detect mode, seems more suitable route rules are configured by Auto Detect mode whenever the wg .cong file looks like. We will discuss this internally.
Thank you.
1 Like
This isn’t working the way I expect, and I don’t think it is actually solved.
I have an openvpn server running on an Asus router, set up so that clients that connect can connect both the the LAN behind the Asus, and also access the internet over the tunnel. So the openvpn server pushes both a route to the LAN behind the Asus, and also pushes redirect-gateway. On a Beryl with 4.1 or 4.2 loaded, and a Beryl with 4.2b loaded, with Auto-detect selected, a connection is made, and I can access devices on the LAN behind the Asus, but my internet traffic does not go over the tunnel (a tracert shows this). So it is as if the Beryl and Beryl AX are executing a “pull-filter ignore redirect-gateway” command.
If I turn on Global Proxy, then internet traffic clearly goes over the tunnel, and I can still access devices on the LAN behind the Asus.
I’m going to load 3.215 on the Beryl and see if the expected behavior is restored.
EDIT: On 3.215 the Beryl sends internet traffic over the tunnel as expected, but the ignore redirect command isn’t observed.
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…
I will watch to see how this develops.
k.
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.
I know now where to look.
1 Like
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.
The original post only describe the issue to access remote LAN, not Internet.
If you have problem accessing Internet, it should be a different issue.
Internet is working with current settings.
I’d suggest that you try the latest firmware. If still have the issue, you can use the solution in this post.
Have latest firmware on both ends 4.4.6 and “auto” proxy. If IP masquerading is turned off, then internet access stops for wifi client.
I’m guessing at this stage the problem is how the router manages multiple layers of identification.
Apparently Wireguard is happy to know one connection has one MAC address. Appears this is lost if i try to use IOS Wireguard over wifi via repeater.
MTU may be a problem on router wireguard client?? Seems to default to 1420 even if i delete it.