Wireguard VPN between Flint (Server) and Slate AX (client) works, but Slate's LAN Clients not able to use it

Hello,

I have the following setup:
Flint (192.168.10.1) → 3rd party router (192.168.100.1) → internet
Slate AX (192.168.20.1) → 3rd party router (192.168.179.1)-> internet

VPN Setup:
Flint: Wireguard VPN Server
Slate AX: Wireguard VPN Client

Flint and Slate AX are running V4.1.0

Situation:
The VPN connection between Slate AX as a client and Flint as a server is established.

Issue:
The clients connected to Slate AX are not able to reach anything, when VPN connection is established. But the Slate AX itself is able to reach everything (LAN 192.168.10.0, LAN 192.168.100.0 and internet [over Flint’s internet connection]).

Question:
Why are the clients, which are connected to Slate AX, not able to communicate over the VPN connection?

a further test I have done
I stopped the VPN connection on the Slate AX. On a client, connected to Slate AX, I installed and configured a Wireguard Client to connect with the Flint. Connection works and the client is able to reach everything (LAN 192.168.10.0, LAN 192.168.100.0 and internet [over Flint’s internet connection])

my conclusion
Something with the Slate AX configuration must be wrong and that is reason why his clients are not able to user his VPN connection. Unfortunately I am not able to figure it out.

Has anybody an idea how to solve the issue?

Regards,
Stanley

It sounds like the firewall rules are not being created properly on the Slate. Have you tried a full reset of the Slate and set things up again?

Also, what is the IP range on the second third party router, just for completeness?

The LAN of the second third party router is 192.168.179.0.

I do not have tried a full reset, because it is a new device.

Are you running the latest version of v4.1.0 on the Slate (i.e., not one of the “release” beta builds that came along the way)?

What are your AllowedIPs on the Slate side (I assume 0.0.0.0/0, but again, just for completeness)?

On Flint:
4.1.0 release 6 (OpenWrt 21.02-SNAPSHOT r16399+157-c67509efd7)

On Slate:
4.1.0 release 7 (OpenWrt 21.02-SNAPSHOT r16399+157-c67509efd7)

The Wireguard config on the Slate is:

Config
[Interface]
Address = 10.0.0.2/24
ListenPort = 12087
PrivateKey = xxx
DNS = 64.6.64.6
MTU = 1420

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = x.x.x.x:51820
PersistentKeepalive = 25
PublicKey = xxx

My understanding is, that all IP’s are allowed.

As a first debugging step I’d recommend installing the final 4.1 versions on both routers. That’s unlikely to be the problem but there were enough things being changed that it’s worth a first shot.

https://dl.gl-inet.com/?model=axt1800

https://dl.gl-inet.com/?model=ax1800

And yes, 0.0.0.0/0 is all IPv4 addresses. The fact the Slate itself can access but clients can’t suggests it’s a problem with the LAN firewall rules. If this were stock OpenWRT it would be easier to debug, but I’m not sure what gl-inet are doing in the background on rules.

One other potential consideration would be to see if OpenVPN works. Both of those devices ought to be capable of 150mbps on the OVPN side, which is generally more than sufficient for most applications. OpenVPN uses a different routing structure which is (imo) easier to debug and in some ways more flexible.

But that’s kind of up to you. We can keep going down this route a while if you want too.

The installed versions are the latest one.

The idea with OpenVPN I also had, but WireGuard should also work. The Slate is designed to work as a WireGuard client, nothing special.

Do you have 192.168.20.0/24 included on the Flint?

I find a solution, which I do not understand. I have on the Slate to activate the IP Masquerading for the Wireguard Client and then it is working for the Slate’s LAN Clients.

Everything is now reachable for the Slate’s LAN Clients.

Where should I have included it?

You shouldn’t have to explicitly, but yes, masquerade has to be enabled for it to work.

This option should be enabled by default. It is cretical for NAT.

Turnning this off will only applicable to some Site2Site scenarios, e.g. both the server and client use the same subnet.