Bug: Wireguard Client Split Tunnel not routing all allowed_ips

jswee1 · 2021-12-13T21:15:18.954Z

I tried @Riho-shuu suggestion didn’t work and tried 3.211 beta 2. Unless I’m doing something wrong I think this is still an issue.

liquidate · 2022-02-07T04:52:06.036Z

I’m having this issue with a GL-AX1800 running 3.208 (no betas available to download). I need to be able to define multiple allowed IPs. I was hoping to purchase multiple units to deploy, but I’ll need to wait until this is addressed.

robotluo · 2022-02-07T08:09:36.126Z

AX1800 has not yet fixed this BUG, the fixed code will be incorporated in the next release.

liquidate · 2022-02-07T16:38:24.218Z

Thank you for the quick reply. Is there an estimate for when the new firmware will be made available? I apologize if this is already published somewhere else, I’m still new to GL.iNet products.

deepsheet · 2022-04-20T19:58:51.540Z

I got bitten by this bug today

Any updates @robotluo / @alzhao? I’m using a GL-E750 / Mudi with firmware version 3.211

alzhao · 2022-04-22T05:05:24.752Z

I tried MT1300 3.212 beta3 and the split routing works.

Can you also try 3.212 beta3? GL.iNet download center

deepsheet · 2022-04-22T08:05:32.531Z

I just flashed it successfully. When adding “10.0.0.0/24, 192.168.1.0/24, 192.168.2.0/24” to Allowed IPs, I get “Invalid AllowedIPs” and it doesn’t save.

alzhao · 2022-04-22T08:56:49.062Z

Can you add the wirguard by post the whole config file?

When edit each filed it has the “Invalid AllowedIPs” bug. But when add as a config file it is OK.

deepsheet · 2022-04-22T09:47:54.111Z

Yes you are correct. I added the config file by hand and now I can see:

root@GL-E750:~# wg show wg0
interface: wg0
  public key: (redacted)
  private key: (hidden)
  listening port: 33782

peer: (redacted)
  endpoint: (redacted):51820
  allowed ips: 10.0.0.0/24, 192.168.1.0/24, 192.168.2.0/24
  latest handshake: 1 minute, 40 seconds ago
  transfer: 476 B received, 692 B sent
  persistent keepalive: every 25 seconds

But again I cannot access anything in 192.168.1.0/24 or 192.168.2.0/24

alzhao · 2022-04-22T09:55:59.732Z

Can you confirm it is 3.212 beta3?

deepsheet · 2022-04-22T13:13:53.234Z

alzhao:

Can you confirm it is 3.212 beta3?

I’ve downloaded the firmware from here:

alzhao:

Can you also try 3.212 beta3? GL.iNet download center

Filename is openwrt-e750-3.212-0407.tar and modem shows:

Screenshot 2022-04-22 at 16.13.291220×414 23.7 KB

chatelp · 2022-05-03T17:00:19.414Z

I have the same problem on Beryl/MT-1300, even when using the latest beta firmware.
Basically I want to have access to both Web and remote network through wireguard.
Using the web interface,

if I use AllowedIPs = 0.0.0.0/0 → I can access only web, which is expected since this subnet is said to preclude local network access.
if I use AllowedIPs = 192.168.1.0/24 (my remote network where the WG server is) I can only access the remote network and not web (that’s also expected)
if I want to use AllowedIPs = 0.0.0.0/0, ::/0, 192.168.1.0/24 → I can’t enter it via web interface, and using the aforementioned command line method it doesn’t work either. It is set (wg command shows me it is set) but network is not working.
I also tried AllowedIPs = 0.0.0.0/1, 128.0.0.0/1 to no avail, only web access and no remote network access

Please help

michaelb · 2022-05-22T11:12:46.372Z

Same issues for me; AR750; 3.212 (non-beta). I had a good config, but it started ignoring my second address at some point. The first address in the allowedip’s line was handled fine.
wg setconf hack doesn’t help.
Looking, it seems that the only issue is the route, so as a workaround, I simply added the route in; since I keep the connection up, this is fine for me; but it could easily be added to a cron too (since it won’t add if the wg0 interface isn’t up).
So @deepsheet would need

route add -net 192.168.1.0 netmask 255.255.255.0 metric 0 dev wg0
route add -net 192.168.2.0 netmask 255.255.255.0 metric 0 dev wg0

alzhao · 2022-05-24T10:00:21.693Z

Wireguard split route in firmware 3.x does have problems.

In firmware 4.x we improved vpn with custom router so pls wait for 4.x firmware.

s.okamoto · 2022-06-18T03:35:32.641Z

there is a flaw in the processing of /etc/init.d/wireguard and multiple routes are not configured.

currently, the value obtained from allowed_ips is treated as two values, ipv4 and ipv6.
this can be resolved by treating them as a list of multiple ip addresses.

it is also possible to enable the DNS servers specified in the WireGuard configuration by reloading dnsmasq after connecting.

I have a patch for GL-SF1200 v3.212 (gl-wg_3.0.95-2_mips_siflower.ipk), Would there a problem writing it here?

alzhao · 2022-06-20T06:40:04.040Z

s.okamoto:

Would there a problem writing it here?

No problem. Can you post?

s.okamoto · 2022-06-20T07:38:13.947Z

thank you alzhao.

there is patch for /etc/init.d/wireguard.
this will enable even if multiple prefixes are described in AllowedIPs.
wireguard.zip (1.0 KB)

alzhao · 2022-06-20T08:24:32.332Z

I asked developer to have a check and merge it in firmware 3.215.

reball · 2022-09-16T10:15:30.202Z

I see that firmware 3.215 beta3 is available (for Beryl) with has a bugfix as below

Fixed WireGuard manual edit allowedip parsing error.

…which I assume is this issue?

However, even with 3.215 beta3 I still cannot get a split tunnel working correctly over 2 subnets, as well as still get the “Invalid AllowedIPs” when editing/saving the config.

This still seems an issue, @alzhao can you (or other cusotmers) please confirm?

To remove any confusion, my process is below:

Add new WG VPN profile with the config below

[Interface]
PrivateKey = <redacted>
Address = 10.6.0.9/24
DNS = 10.6.0.1

[Peer]
PublicKey = <redacted>
PresharedKey = <redacted>
Endpoint = <redacted>:51821
AllowedIPs = 192.168.10.0/24, 192.168.55.0/24

Save and connect
I can succesfully ping 8.8.8.8, 192.168.10.1, but cannot ping 192.168.55.1.
Disconnect the VPN and edit it.
Check that the “Allowed IPs” is “192.168.10.0/24, 192.168.55.0/24”, click save, and get the “Invalid AllowedIPs” error.

My expected outcome is that all traffic on 192.168.10.0/24 and 192.168.55.0/24 goes through the VPN, everything else bypasses the VPN.

I can provide more details if required.

Edit: Type

alzhao · 2022-09-16T10:20:16.115Z

I reopened the bug internally.