Trouble reaching IP behind WireGuard VPN on simple access point

Installing and Using OpenWrt Network and Wireless Configuration
1

Hi all, first post here. I've installed OpenWRT on an ASUS RX-AX53U and I'm loving it so far. However, there's a problem that I don't seem to get fixed no matter what I try.

On another network, I've configured a WireGuard server. With some iptables magic I've managed to bind ports to the servers VPN address (let's say it's 10.10.10.1). For the record: on both Windows clients and Linux clients this works as intended. I can connect to the VPN and go to. 10.10.10.1:80 in a browser.

Multiple clients may connect to this VPN and have a different IP, but let's consider for a moment 10.10.10.2 to be the client I'm configuring right now.

I've followed the 'dumb' AP configuration guide. This configuration seems to work.

I've then used a variety of tutorials such as this one to configure WireGuard.

Basically, these are the steps:

  1. Add a new interface and import the WireGuard settings from a (working) configuration file.
  2. Check 'Route Allowed IPs' in the single peer that is present and set 'Persistent Keep Alive' to 25 (according to ChatGPT this is necessary when using NAT).
  3. Create a new firewall zone for the WireGuard interface and forward to LAN. Set all to ACCEPT. I also enabled MSS clamping.
  4. I also forwarded from the LAN back to the WireGuard zone. Set all to ACCEPT. Not sure this is needed.
  5. Enable masquerading on the WireGuard zone.

These are the resulting zones:

image
image949×229 88.4 KB

I also experimented a bit with a forward rule from LAN to WireGuard in 'Traffic Rules' but that didn't work either.

Could someone explain to me what I'm doing wrong? I'm a beginner when it comes to networking, so I'm probably missing something obvious.

2

Wireguard differentiates peers by their public key. This means that private_keys (which are 1:1 with a public_key) cannot be reused. Generate a new private_key on your client and register the corresponding public_key into the server. Preshared keys may be reused for multiple clients.

Run wg show to confirm that the peer has a recent handshake. Failure to handshake is due to mismatched keys or a network / firewall problem with the outer encrypted packets. The persistent_keepalive setting is recommended as it forces an initial handshake even if no data is being sent into the inner tunnel, and then periodic null packets are sent to keep the outer NAT open.

Typically a network like this would be set up without NAT on the inner traffic. This is done by making sure that all LANs on the other side are allowed_ips, and using route_allowed_ips or manually installed routes to make routes to the remote LANs.

3

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/firewall
wg show

And let’s see the remote peer config, as well.

4

Thank you so much for the advice, l'll get right to it after dinner.

Sam

5

Generate a new private_key on your client and register the corresponding public_key into the server.

I didn't make that clear, but I make sure to always use only 1 client per device. The client keys aren't shared.

Run wg show to confirm that the peer has a recent handshake.

Yes, apparently the handshake was successful.

Typically a network like this would be set up without NAT on the inner traffic.

Well ... Here's the thing: on the server the services are filtered and port forwarded to the wg0 interface. That way I don't expose my entire LAN. It might not be perfect but because it works on my laptop I expect it to work on the router.

6

Thanks for the help. Here are the results. I've changed the IPs so we can still talk about them.

ubus call system board

{
	"kernel": "5.15.162",
	"hostname": "OpenWrt",
	"system": "MediaTek MT7621 ver:1 eco:3",
	"model": "ASUS RT-AX53U",
	"board_name": "asus,rt-ax53u",
	"rootfs_type": "squashfs",
	"release": {
		"distribution": "OpenWrt",
		"version": "23.05.4",
		"revision": "r24012-d8dd03c46f",
		"target": "ramips/mt7621",
		"description": "OpenWrt 23.05.4 r24012-d8dd03c46f"
	}
}

cat /etc/config/network

config interface 'loopback'
	option device 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdc9:832b:3170::/48'
	option packet_steering '1'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.115.51'
	option netmask '255.255.255.0'
	option ip6assign '60'
	option gateway '192.168.115.1'
	list dns '8.8.8.8'
	list dns '8.8.4.4'

config interface 'samlab'
	option proto 'wireguard'
	option private_key '[redacted]'
	option listen_port '51821'
	list addresses '10.10.10.5/24'

config wireguard_samlab
	option description 'Imported peer configuration'
	option public_key '[redacted]
	option preshared_key '[redacted]'
	list allowed_ips '10.5.5.0/24'
	option endpoint_host '[redacted]'
	option endpoint_port '51821'
	option persistent_keepalive '25'
	option route_allowed_ips '1'

cat /etc/config/firewall

config defaults
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'

config zone
	option name 'wg'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'samlab'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'wg'
	option dest 'lan'

config forwarding
	option src 'lan'
	option dest 'wg'

wg show

interface: samlab
  public key: [redacted]
  private key: (hidden)
  listening port: 51821

peer: [redacted]
  preshared key: (hidden)
  endpoint: [redacted]:51821
  allowed ips: 10.10.10.0/24
  latest handshake: 1 minute, 29 seconds ago
  transfer: 460 B received, 1.60 KiB sent
  persistent keepalive: every 25 seconds
7

This might actually be a problem; I'm not sure ... It is far from perfect: if I go with my laptop to any other VPN address other than 10.10.10.1 or my client 10.10.10.2, then I still get access to the same services as on 10.10.10.1. So it's definitely something that I have to re-configure at some point.

8

Delete option masq '1' on the wg zone

But you need to enable it on the lan zone as this is a bridged ap

The list address of the server can be 10.10.10.5/24 but usually you take the first address e.g 10.10.10.1/24

The allowed ip is the clients ip address that usually is in the same subnet as the server so a regular ip address/ allowed ips would be 10.5.5.2/32
Note that it is not neccessary you can set any address as long as it corresponds with the address of the client, but then make sure you enable route allowed ips.

So your setup is not wrong but unusual so check that that is what you want

9

The allowed_ips don't make sense. Remember that allowed_ips are the source IPs that you expect to see from the other side of the tunnel. This is the most complicated part of Wireguard.

If your tunnel is point to point, you can set allowed_ips to 0.0.0.0/0 on both ends then configure routing and firewall rules separately. If there are multiple peers connected to a peer, those allowed_ips must be a non-overlapping set as it controls which peer a packet will be encrypted for and sent to.

It is possible (and recommended) to use symmetric routing and then have firewall rules that limit access to/from certain IPs and ports. As a simple case, writing only one config forward instead of a pair for both directions means the connections will be stateful firewalled to be one-way only. It works the same as having masquerade except that the addresses are not changed.

1 Like
10

Thanks! I'll take a look at it tomorrow morning.

11

It's a client. Maybe that explains the difference?

Delete option masq '1' on the wg zone
[...]
But you need to enable it on the lan zone as this is a bridged ap

Thanks! Done!

Note that it is not neccessary you can set any address as long as it corresponds with the address of the client, but then make sure you enable route allowed ips.

I think this is what I want. 'Route Allowed IPs' is on.

12

Does it make sense if this router is a client and I want to 'allow' this client to see all remote VPN IPs?

It is possible (and recommended) to use symmetric routing and then have firewall rules that limit access to/from certain IPs and ports. As

I guess my question boils down to: how to configure such a firewall on OpenWRT?

As a simple case, writing only one config forward instead of a pair for both directions means the connections will be stateful firewalled to be one-way only. It works the same as having masquerade except that the addresses are not changed.

I'll try this but I'm not sure this is enough to solve the network issues.

13

For a regular WG client you actually need the masq enabled on the WG interface.
But you say you want to reach network clients on this side so that is more like a server setup.

What is on the other side, can you post a config of the other side?

14

No sorry, I want to reach network clients on the other side (one client in particular).

I'll post my configuration later today. It is nothing fancy, except that certain services get 'port forwarded' to the server interface, making them available on the server's VPN IP address.

15

One interesting thing is that wg show indicates that some limited data is transferred, so it appears that this is a routing or firewall issue.

Using telnet on the router itself to ping a service on the remote server also doesn't work.

16

Ok then keep masquerading enabled on the wg zone.

The problem could be the allowed ips.
Add as allowed ips at least the wg subnet so
10.10.10.0/24 and all subnets of the other side e.g from br-lan, guest interfaces etc.
As you have route allowed ips turned on this will also set the necessecary routes to the other side via the tunnel

In addition the other side has to allow traffic from the wg subnet 10.10.10.0/24 also the individual clients on the other side will have a firewall which by default only allows traffic from their own subnet and not from the wg subnet

17

Could you draw a diagram that shows the two endpoints, how they are connected to each network, and the desired access direction/flow? Please be sure to include the ip addresses of the key devices.

2 Likes
18

Here it is, finally. Not my best work, but I hope it is good enough.

network
network699×321 19.5 KB

After some investigating I noticed that traceroute 10.10.10.1 always directly hops to the default gateway in my network instead of my WireGuard VPN. I'm suspecting that's where the problem lies, but I'm not sure how to continue.

Some notes:

  • Device 1 should be able to reach the services on 10.10.10.1
  • The 'port forwarding' does two things: acting as a firewall (only a select amount of services are forwarded) and hiding the IP of the main server. Even if this IP changes, the setup on the other side will keep working.
19

You have indeed identified the fact that device 1 has a default gateway of 192.168.115.1. It is not aware of the WG gateway.

There are a few ways to handle this (choose one option only)…

  1. If your main router at that location (192.168.115.1) supports static routes, you can set one for 10.10.10.0/24 via 192.168.115.51 and that will direct the traffic properly.
  2. you can create a second network behind 192.168.115.51 such that the default route always goes through this device. The routing on that system will properly handle the appropriate routes.
  3. You can add the static route (discussed in option 1) directly to device 1 (if supported) so that device 1 knows how to reach the WG interface and devices behind it at the remote side.
20

Awesome, thanks for the tips! I'll let you know how it goes!