VPN Peer's Allowed IP routing prevents other zones from reaching Internet

I have a lan zone (192.168.1.x) for wired and a guest zone (10.20.30.x) for wireless. My lan zone is forwarded to the vpn while the guest zone is forwarded to the wan.

The problem is that when I check the box for the wireguard vpn peer to route the allowed IPs of 0.0.0.0/0, that breaks the Internet connection for the wifi devices in the guest zone. However, if I don't check that box, then the lan zone devices will lose the Internet (fixed by adding the static route mentioned below, but the problem with the wifi devices still exists).

There must be some sort of route that I need to create in order to allow the guests to be able to connect still, but I'm not sure how to do it.

Any help would be greatly appreciated. Thanks!

image

To route only LAN to VPN:

config route
        option target '0.0.0.0'
        option netmask '0.0.0.0'
        option table '1' #<---number used, or add name to a file, see Wiki
        option interface 'wg' #<--use name of wg interface

config rule
        option src '192.168.1.0/24'
        option dest '0.0.0.0/0'
        option priority '1' #<---IP Rule No - not same as table
        option lookup '1'#<--- table No

Odd, seems like somehow you routed the endpoint IP too.

Thanks for the reply!

Unfortunately, disabling the "route to allowed IPs" option and adding your recommended static route accomplishes the same thing as enabling the "route to allowed IPs". That route being created by either method removes the ability of the guest devices to connect to the Internet. At least I'm not getting that handshake error in either configuration and the wireguard connection is established and lan devices working as before. It's just the guest devices that can't connect when either of these routing configurations are present.

The firewall allow rule from 192.168.1.0/24 to 0.0.0.0/24 didn't make a difference. That source IP is for the lan and isn't required with either route configuration to get the lan devices Internet access. Is there perhaps a route that needs to be created for the guest devices as well?

The firewall sets what is allowed. The actual routing is controlled by the routing table(s). If you want some networks to use direct Internet (not VPN) and others to use VPN, you will need multiple routing tables underpinning the allow forwards in the firewall. Again the firewall does not decide where a packet will be sent. It does decide if it will be allowed through after the kernel routing system decides where to send it.

Policy based routing can be useful to set up multiple default routes.

It is necessary to control the routes outside of Wireguard, so do not check "route allowed IPs". However, allowed IPs needs to be 0.0.0.0/0 so that any Internet site can be passed through the tunnel.

1 Like

@mk24 is correct:

  • keep allowed IPs as 0.0.0.0/0 (i.e. the whole Internet)
  • adjust/verify firewall to allow LAN-to-VPN and Guest-to-WAN
  • the route and rule above makes the policy exception for LAN to route to VPN
  • the default route and rule will work for Guest to route to WAN as normal

Here's another way to implement this task with just custom routing tables and rules:

This way, static routes can be removed by enabling route allowed IPs.

Thanks everyone for attempting to educate me, but I still don't understand what to do to fix this issue and going over routes and rules and everything has only made me more confused.

Correct me if I'm wrong, but how a routing table works is it tells the router to send a packet which indicates it is intended for the specified IP address to the interface/network specified by the routing table. So a static route with a target of 0.0.0.0/0 for the "vpn" interface would route all packages intended for any IPv4 address to the "vpn" interface, wouldn't it? If that's the case, why is it sending packets intended for other peers on the "lan" network to the "lan" interface? Is that rule being overridden by the other static route rule of sending 192.168.1.0/24 to "lan"?

What I need is for packets for all non-private IP addresses to be sent to the "vpn" interface if they originate from a "lan" node, and for packets for all non-private IP addresses to be sent to the "wan" interface if they originate from a "guest" node. So wouldn't a static route of all IP addresses (0.0.0.0/0) routed to the "vpn" interface help to cause the very problem of packets in the "guest" network not being able to send non-private packets to the "wan" network since it's trying to redirect them to the "vpn" network instead and can't do so because of the firewall zone restriction?

2 Likes

I followed the "Route LAN to VPN and DMZ to WAN" guide and now I have a rule that says if coming from "lan", do...nothing? Not sure what the point of the rule is, and if I change the destination to "vpn" I'm worried it will brick me out, again, for the umpteenth time, just like with the below config. It did change one major thing, though, in that now all of my LAN traffic is being routed to the WAN even though I have it forwarding the lan zone to the vpn zone so I don't know how that is happening.

This config here below has bricked me out several times. I don't know why luci isn't reverting the changes after waiting 90 seconds, but it doesn't. Restarting the router fails and I have to do a hard reset. This config is directing all traffic intended for the LAN to the VPN which means communication with the router is suddenly impossible. Perhaps if it was using a higher metric than the route which directs all 192.168.1.0/24 traffic to the "lan" interface, it would work?

It's really frustrating spending a month on trying to configure a router and constantly running into a snag when just trying to do what should be a fairly simple thing. It'd be great if there was a simpler easy web interface for users who aren't steeped in knowledge of networking and various routing software subsystems.

There is:

I'm not sure what you're referring to. If you mean 0.0.0.0/0 - that means the whole Internet - not "nothing".

Saving the config I posted shouldn't "brick you out" - given it has nothing to do with traffic destined for the router itself.

Your router exists on the same network, it's input. Perhaps you're [incorrectly] using the IP of another interface?

For example, the default LAN router IP on OpenWrt is 192.168.1.1. If you access the router from a client on LAN - use that IP. You shouldn't get locked out.

(Are you trying to do this config remotely, perhaps?)

1 Like

Let's verify your configuration:

ip address show; ip route show table all; ip rule show; wg show
uci show network; uci show dhcp; uci show firewall
1 Like