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.
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:
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.
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:
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?
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
you can access the desired network resources, and
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.
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.
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.
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.
# 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.
. With that in mind, below is the config that worked for a little while:
