Wireguard / OpenVPN connects but no LAN Access when running in Repeater Mode?

Was using 4.2.0 beta 4 but now on today’s snapshot.

Is there a log I could supply ?

OK, I took two logs (this is copy paste from the GLiNEt WebAdmin, apologies for formatting, it came out like that). Plus two screencaps showing Repeater and VPN were connected (but nothing went through).

I am not sure if this can help identify anything?

I can try and get something from the Router they connect to, noting again that using a VPN through the phone directly, same wifi, same VPN profiles same VON Server works fine; just not when the profiles are used in the Router.


oVPN

“Tue Feb 21 08:04:30 2023 daemon.notice netifd: ovpnclient (17744): udhcpc: sending discover\nTue Feb 21 08:04:33 2023 daemon.notice netifd: ovpnclient (17744): udhcpc: no lease, failing\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: Interface ovpnclient.IPv4 no longer relevant for mDNS.\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: Leaving mDNS multicast group on interface ovpnclient.IPv4 with address 10.8.0.2.\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: Withdrawing address record for 10.8.0.2 on ovpnclient.\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: Joining mDNS multicast group on interface ovpnclient.IPv6 with address .\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: New relevant interface ovpnclient.IPv6 for mDNS.\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: Registering new address record for on ovpnclient.*.\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: Joining mDNS multicast group on interface ovpnclient.IPv4 with address 10.8.0.2.\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: New relevant interface ovpnclient.IPv4 for mDNS.\nTue Feb 21 08:04:33 2023 daemon.info avahi-daemon[3388]: Registering new address record for 10.8.0.2 on ovpnclient.IPv4.\nTue Feb 21 08:04:33 2023 daemon.notice netifd: Interface ‘ovpnclient’ is now up\nTue Feb 21 08:04:33 2023 daemon.notice netifd: Network device ‘ovpnclient’ link is up\nTue Feb 21 08:04:33 2023 daemon.notice netifd: ovpnclient (17744): route: SIOCDELRT: No such process\nTue Feb 21 08:04:33 2023 daemon.notice netifd: ovpnclient (17744): route: SIOCDELRT: No such process\nTue Feb 21 08:04:33 2023 user.notice mwan3[18935]: Execute ifup event on interface ovpnclient (ovpnclient)\nTue Feb 21 08:04:33 2023 user.notice mwan3[18935]: Starting tracker on interface ovpnclient (ovpnclient)\nTue Feb 21 08:04:35 2023 user.notice firewall: Reloading firewall due to ifup of ovpnclient (ovpnclient)\nTue Feb 21 08:04:35 2023 daemon.warn ovpnclient[17744]: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this\nTue Feb 21 08:04:35 2023 daemon.notice ovpnclient[17744]: Initialization Sequence Completed\n”

WG

“Tue Feb 21 08:08:15 2023 daemon.notice netifd: Interface ‘wgclient’ is setting up now\nTue Feb 21 08:08:18 2023 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=1 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/\nTue Feb 21 08:08:21 2023 daemon.notice netifd: Interface ‘wgclient’ is now up\nTue Feb 21 08:08:21 2023 daemon.notice netifd: Network device ‘wgclient’ link is up\nTue Feb 21 08:08:22 2023 user.notice mwan3[27184]: Execute ifup event on interface wgclient (wgclient)\nTue Feb 21 08:08:22 2023 user.notice mwan3[27184]: Starting tracker on interface wgclient (wgclient)\nTue Feb 21 08:08:23 2023 user.notice firewall: Reloading firewall due to ifup of wgclient (wgclient)\nTue Feb 21 08:08:25 2023 user.notice wgclient-up: env value:T_J_A1_1=object T_J_V_ifname=string USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=2 J_V_keep=1 T_J_V_ipaddr=array HOME=/ T_J_T2_mask=string HOTPLUG_TYPE=wireguard T_J_V_interface=string J_A1_1=J_T2 J_V_ifname=wgclient T_J_V_link_up=boolean T_J_T2_ipaddr=string LOGNAME=root DEVICENAME= T_J_V_action=int K_J_A1= 1 J_V_ipaddr=J_A1 TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin J_T2_mask=32 CONFIG_LIST_STATE= J_V_interface=wgclient K_J_V= action ifname link_up keep ipaddr interface J_V_link_up=1 J_T2_ipaddr=10.6.0.4 J_V_action=0 N_J_V_link_up=link-up PROTO_IPADDR=10.6.0.4/32// T_J_V_keep=boolean PWD=/ JSON_CUR=J_V K_J_T2= ipaddr mask CONFIG_SECTIONS=global AzireVPN Mullvad FromApp group_1695 group_4662 group_7629 peer_8189 CONFIG_cfg030f15_ports=\nTue Feb 21 08:08:25 2023 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=1 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/\n”

I attach my Server (ASUS RT-AX86U) and Client (In Beryl AX Router, does not work) and Peer Profiles (in iPhone, Works).

FYI in my Asus Router I use Cloudflare 1.1.1.1 an 1.0.0.1 as DNS Servers, hence why the former is added to the WG config. I did try adding 1.1.1.1 as an additional DNS to the WG VPN Client config in the Beryl AX Router too; but that still doesn’t work (it is removed again as shown below).


alzhao or anyone? I provided all the details I could … any ideas please?

Does this ping get any replay?

ping 10.0.0.1 -I wgclient

10.0.0.1 is the wireguard server tunnal IP.

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?

  1. Noted on 10.6.0.1. I tried that and no change to the ping result. See here:

  1. 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.



  1. 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:

  1. Default route:
  • Global: VPN tunnel
  • Auto: Parse “wireguard.conf” file for “wgclient” and parse OpenVPN server push option for “ovpnclient”
  1. Firewall LAN-WAN forward:
  • Global: Not allowed by default
  • Auto: Allowed by default
  1. 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.