Wireguard VPN for accessing LAN (can handshake, can't communicate)

My goal is to connect to my LAN (10.11.12.xxx) from the WAN using Wireguard (same goal as this unsuccessful attempt). I had this working a year ago, recently nuked my router, and I can't get it working again. I can confirm that my client is making the handshake and transferring some data to the server, but I'm not able to ping the router nor any of the machines on the LAN.

SERVER
config interface 'wg0'
	option proto 'wireguard'
	option listen_port '123'
	list addresses '10.11.12.1/24'
	option private_key 'REDACTED'

config wireguard_wg0
	option persistent_keepalive '25'
	option route_allowed_ips '1'
	option public_key 'REDACTED'
	list allowed_ips '10.11.12.210/32'

CLIENT
[Interface]
PrivateKey = REDACTED
ListenPort = 25812
Address = 10.11.12.210/24

[Peer]
PublicKey = REDACTED
AllowedIPs = 10.11.12.1/24
Endpoint = redacted.com:123
PersistentKeepalive = 25

It's probably a firewall problem, but I just can't figure it out. I added the wireguard interface to the LAN group, and I restricted to IPV4, because I had a vague memory of that fixing a problem in the past...

There are so many great tutorials about how to set something like this up, but not as much about how to methodically debug when it has gone wrong. Any hints?

Wg0 does not bridge to the LAN, so you cannot ping devices in the LAN.
You should create a zone for wg0 alone and then allow wg to be forwarded to the LAN.
example:

config zone 'wireguard'
	option name 'wireguard'
	option input 'ACCEPT'
	option forward 'ACCEPT'
	option output 'ACCEPT'
	option masq '1'
	option mtu_fix '1'
	option device 'wg0'

config forwarding 'wireguard_wan'
	option src 'wireguard'
	option dest 'wan'

config forwarding 'wireguard_lan'
	option src 'wireguard'
	option dest 'lan'

config forwarding 'lan_wireguard'
	option src 'lan'
	option dest 'wireguard'
2 Likes

In addition to our firewall advice, you should fix a few things in your client configuration:


CLIENT
[Interface]
PrivateKey = REDACTED
# removed listen port
Address = 10.11.12.210/32 #changed this to /32

[Peer]
PublicKey = REDACTED
AllowedIPs = 0.0.0.0/0 # changed this so the client will route all traffic through the tunnel.
Endpoint = redacted.com:123
PersistentKeepalive = 25

Also consider changing the the wg listen port on your openwrt side - udp 123 is used for ntp. Maybe use 8123 instead.

2 Likes

Thanks very much for the help! I don't want to route all my traffic through the VPN, only the 10.11.12.xxx subnet. I adopted all of the firewall changes:

And I made this change to my client config:

CLIENT
[Interface]
Address = 10.11.12.210/32 #changed this to /32

I can now ping my router 10.11.12.1, but I can't ping anything else on the LAN (10.11.12.200 is the box I especially need to reach.)

$ traceroute 10.11.12.1
traceroute to 10.11.12.1 (10.11.12.1), 64 hops max, 52 byte packets
 1  10.11.12.1 (10.11.12.1)  87.211 ms  221.934 ms *
$ traceroute 10.11.12.200
traceroute to 10.11.12.200 (10.11.12.200), 64 hops max, 52 byte packets
 1  10.11.12.1 (10.11.12.1)  65.314 ms  117.673 ms  77.166 ms
 2  * * *
 3  * * *
 4  * * *

I also systematically tried checking disabling Masquerading and MSS clamping for the wireguard group, as well as keeping my client address as /24. All of them allow me to ping the router, but none of them let me get into the LAN.

Are there other tools I can use to understand what happens to my packet that's headed to .200 after it gets received at .1?

This is from your 'client' side config.

Chang this as follows:
10.11.12.0/24 --> refers to the network (rather than a specific host as you have defined now). This is your WG network, though... so this won't get you to your LAN.

192.168.1.0/24 ---> (assuming your router's LAN IP is 192.168.1.x, if not, change this accordingly) -- this Change this to your lan network definition if you want to access your LAN. Similarly, you can specify other networks or even larger subnets.

As an aside, setting this to 0.0.0.0/0 will actually be a good test to see if

  1. you can access the desired network resources, and
  2. you can access the internet via the WG connection - a traceroute to any internet address can help you check that you are indeed passing traffic through the tunnel since the first hop should be 10.11.12.1.

Once you know WG is working, then you can narrow down the scope of what addresses/network(s) should pass through the tunnel.

Just noticed that it appears you are using the same network for WG as you are for your LAN -- is this true?

I'd recommend using a different network on your WG config. Could be any RFC1918, really -- maybe 10.9.8.0/24 (with the WG interface configured as 10.9.8.1/24 and the peer 10.9.8.2/32. Then on the client/peer side, setup allowed IPs for 10.11.12.0/24 to allow access to the entire LAN network, or 10.11.12.200/32 if you only want to allow that singular resource.

Just noticed that it appears you are using the same network for WG as you are for your LAN -- is this true?

It is true, and intentional. I would like for it to be transparent whether a machine is on the LAN or in the outside world on a VPN. My machines have a static IP on the LAN (e.g. 10.11.12.210), and if I take them out into the world and connect over Wireguard, that machine gets the same static IP within the LAN.

Eric Light seems to think I need ProxyARP, and Stavros has some IPTables rules that look like they're basically the same as my current firewall rules.

This must be possible, because all of the following are true:

  • wireguard can ping router(.210 -> .1)
  • box on lan can ping router (.200 -> .1)
  • if I SSH into the router, I can ping out to both wireguard and the lan (.1 -> .200 and .1 -> .210)
  • but wireguard can't ping lan, or vice-versa

I can't find much about ProxyARP on OpenWRT, but I can find these in the package repository, which all seem vaguely related, but not quite right...

AFAIK, it is highly unusual to have the same network defined for both the LAN and the WG interfaces. WG will setup the appropriate routes, so you shouldn't have to worry about it. The ping tests you ran don't really add any new information. Yes, WG remote peer should be able to ping the router. This is normal since WG sets up the appropriate route. A box on the LAN should also be able to ping the router -- again, this is always true (unless you have firewall rules to block such access). And the router also knows about the routes, so it can ping your LAN box and your WG peer. But this would be true even if your WG interface was on a different network as I recommended.

Try what I suggested -- you can always revert if you don't get things working the way you want.

I really do appreciate the help, but I know that it was possible to use the same subnet before. If I switch to using two subnets and it works, I will lose the LAN/VPN transparency, and I'll have to go back and solve the same problem I'm stuck on now. So I'm gonna let this simmer for now, and see if I can't find some debugging tools to understand why the routing isn't happening.

I'm not really sure what 'transparency' you are looking for here, or what problem(s) you have that wouldn't be solved by what has been suggested in this thread. Maybe you can better define why these suggestions are not ideal for your situation.

If you look through the forums, it is clear that you should not be using the same network for WG as you do for LAN. This thread mentions proxy ARP and such, but still explicitly states that it is a bad idea to overlap networks, especially because of the fact that WG is L3 and your other interface is L2.

1 Like

I have a fleet of laptops which also act as continuous integration boxes for running user-interface regression testing. If we have a bug, someone can go to that laptop, pick it up, and start debugging the problem. They can even take it home, and work on the problem there. And so long as they are connected to the VPN, the box will continue to function as a CI box for the rest of the network.

In the past, this was achieved because their IP was always the same, whether they were on the LAN or the VPN. That's the transparency I'm talking about - that it doesn't matter whether a box is on the LAN or VPN, it has the same IP and it can talk to the rest of the 10.11.12.x network. I understand that is bad practice, but it was a very useful practice for us, back when it worked...

So if I understand the issue correctly, the problem you are trying to solve is that a given machine will have an address on the LAN when in one location, and an address that is not the same as the LAN when elsewhere using the WG network?

A potential solution would actually be to just simply always have WG active on the laptop... then it would always be available at the assigned address within the WG, regardless of the location.

1 Like

There is a moment when you realize that you are missing a DNS server or not using it properly.
This sort of architecture flaw if not resolved in time, leads to a whole pile of problems.
The sooner you make it right, the less issues you have to deal with in the future.

2 Likes

Yup, both the always-on WG and a proper DNS for our local network would work. The thing is, we had a working setup, and I have all the backup files to know that this did work at one point, which is why I'm being so stubborn. I really appreciate the help, I certainly hear and accept the advice I've gotten. But other people have wanted this same bad idea, and we had this bad idea working usefully for us, and that's why I'm continuing to bang on this door for now.

Huzzah! It's finally working. The missing trick has been this.

EDIT: It didn't work for long! After adding more peers, it sorta blew up. @psherman said it was a bad idea to have the VPN on the same subnet as the LAN, and he was right! ProxyARP patched it up for a bit, but it did not last :frowning: . With that in mind, below is the config that worked for a little while:

# in /etc/sysctl.conf
net.ipv4.conf.all.proxy_arp = 1

Once I set that, everything else started working. I can go back and forth from LAN to VPN in seconds, and there's no hiccups. There seems to be a strong consensus that this is a bad idea, but it's been quite useful to us.

Here was my final setup, for anyone else who comes along with the same problem.

SERVER
config interface 'wg0'
	option proto 'wireguard'
	option listen_port '123'
	list addresses '10.11.12.1/24'
	option private_key 'REDACTED'

config wireguard_wg0
	option persistent_keepalive '25'
	option route_allowed_ips '1'
	option public_key 'REDACTED'
	list allowed_ips '10.11.12.210/32'

CLIENT
[Interface]
PrivateKey = REDACTED
ListenPort = 25812
Address = 10.11.12.210/32

[Peer]
PublicKey = REDACTED
AllowedIPs = 10.11.12.1/24
Endpoint = redacted.com:123
PersistentKeepalive = 25

In my firewall, I just added the wireguard interface to the lan zone, and forced IPv4.

Thanks for all the help!

https://forum.openwrt.org/uploads/default/original/2X/5/5889c33247e31af0b867556d52507fe9806abd25.png

@ZOzo, I'm not sure about 2018, but today we have:

# opkg files wireguard-tools | grep -e watchdog
/usr/bin/wireguard_watchdog