Wireguard traffic to computer in the remote network affected nonsensically by WAN firewall rules

I don't understand if I misconfigured something and I don't think I did

I have installed wireguard on my router and my wireguard interface has the lan firewall zone assigned, I can connect to the tunnel but I'm only able to access forwarded to WAN ports on computers on the remote network when I connect using their local IP address and their real port, e.g., if I have a ssh port forward active from external port 5448 to 22 to 192.168.1.20, I can ssh to 192.168.1.20 at port 22, but if I have that port forward disabled I can't (even though it's for external 5448)

am I missing something obvious about firewalls?

You should not use port redirects when connected to your own VPN.
Assign the VPN network to the LAN firewall zone on the router and simply use the LAN IPs and ports.
Just make sure the LAN hosts allow incoming traffic outside the local subnet.

the redirects are for traffic from WAN (I have https exposed). precisely traffic via wireguard should not be affected by them but is being. the wireguard interface is already assigned to the LAN zone

1 Like

Collect the diagnostics and post it to pastebin.com redacting the private parts:

ip address show; ip route show table all; ip rule show; iptables-save -c
1 Like

This is wrong, remove the LAN subnet from the VPN interface.

1 Like

with it removed from the VPN, now I can't reach any IP on the LAN subnet but the router itself at 192.168.1.1

uci show network; wg show
1 Like

Also check out the VPN client config.

[Interface]
PrivateKey = ***
Address = 192.168.2.7/32 (I have tried with 192.168.1.7/32 too)
DNS = 192.168.1.20

[Peer]
PublicKey = ***
AllowedIPs = 0.0.0.0/0,::/0
Endpoint = ***
PersistentKeepalive = 30

I don't think there's any issue with the client config, and as I said the connection to the other computers is affected by the port forwards of the router (which is the wg server) so it's definitely something about the router

1 Like

Fundamentally there needs to be three unique subnets involved.

  • the local LAN
  • the remote LAN
  • the VPN tunnel

Each site has an interface that holds one unique IP on the VPN tunnel "backbone" and routes to the other site(s) via that interface. A local site doesn't hold any IP addresses on the remote LAN but it knows how to reach it via a route.

The "allowed_ips" option installs those routes. So you should reference the remote site as an entire network 192.168.2.0/24 not only one IP with a /32.

The command route with no parameters dumps the basic routing table in a concise manner compared to ip route show.

When you trust everything on both LANs you can just put the VPN tunnel into the LAN zone. Make sure that the default "forward" rule on that zone is ACCEPT, (which is the default setting).

Of course it is also possible (but more complicated) to make the VPN a separate zone and explicitly forward through it, possibly with exceptions to block certain traffic.

1 Like

I'm actually using luci. attaching screenshots. I think I've done what you say, adding 192.168.1.0/24 too to allowed IPs on the router because that's the subnet I actually want to reach, but still not working I can't reach even the opened ports anymore

here's route output:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         fixed-(WAN-IP) 0.0.0.0         UG    0      0        0 eth1
(WAN IP)   *               255.255.255.0   U     0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 wg
192.168.2.0     *               255.255.255.0   U     0      0        0 wg

my configuration on luci

I lost connection to the router and so have local machines, they're not getting IPs from it but directly from the modem... I think I'll have to factory reset

There really isn't any need to have IP addresses on the VPN interface since the local and remote LAN addresses can identify the services instead.

2 Likes

sorry for bump but I want to leave the answer that worked for me for anyone that Googles and ends up here: the wireguard port had to be NOT in the "Allow high ports" range of the MiniUPnP ACLs. so you can either use a port lesser than 1024 or change the range :slight_smile:

I don't even know how it makes sense. but everything is working properly now and that was what seems to have fixed it.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.