I've setup a test router with Openwrt 25.12.4 (lan interface 10.11.0.0/24) and installed PBR - I have a wireguard interface successfully handshaking to another router (lan 192.168.5.0/24. )
Both routers are locally sitting behind a local gateway / router on the same wan subnet (192.168.0.0/24)
My objective is to be able to connect from devices on the lan of the test router (lan interface 10.11.0.0/24) to the other router (lan interface 10.11.0.1) (and eventualyl vice versa) but I want to try and get the oneway connection working first.
My reason for using PBR is that I would like to eventually use PBR to have different local interfaces use either the local or remote router's as a wan gateway while being able to maintain connectivity for local traffic between each of the routers
I expected that when I added to the rule to PRB and made the WG interface a Supported Interface that I would see routes added to the routing table and for pings to the remote lan directed throught the WG interface however this doesn't appear to be happening.
By network and PBR configs are included below along with a copy of my routing table.
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 'fd9f:7397:e719::/48'
option dhcp_default_duid '000452a6c4828d3a493e9f8efd6fdd541190'
option packet_steering '1'
config atm-bridge 'atm'
option vpi '1'
option vci '32'
option encaps 'llc'
option payload 'bridged'
option nameprefix 'dsl'
config dsl 'dsl'
option annex 'a'
option tone 'av'
option ds_snr_offset '0'
config device
option name 'br-lan'
option type 'bridge'
list ports 'lan1'
list ports 'lan2'
list ports 'lan3'
list ports 'lan4'
config device
option name 'lan1'
option macaddr '30:24:78:d8:1f:a8'
config device
option name 'lan2'
option macaddr '30:24:78:d8:1f:a8'
config device
option name 'lan3'
option macaddr '30:24:78:d8:1f:a8'
config device
option name 'lan4'
option macaddr '30:24:78:d8:1f:a8'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '10.11.0.1'
option netmask '255.255.255.0'
option ip6assign '60'
option multipath 'off'
config device
option name 'dsl0'
option macaddr '30:24:78:d8:1f:a9'
config interface 'wan'
option device 'wan'
option proto 'dhcp'
option multipath 'off'
config interface 'WgWappingCl'
option proto 'wireguard'
option private_key '<REDACTED>'
list dns '192.168.5.1'
option multipath 'off'
list addresses '10.7.254.11/24'
config wireguard_WgWappingCl
option description 'Imported peer configuration'
option public_key '<REDACTED>'
list allowed_ips '0.0.0.0/0'
list allowed_ips '::/0'
option endpoint_host '<REDACTED>'
option endpoint_port '51720'
option persistent_keepalive '25'
Wireguard
PRB
config pbr 'config'
option enabled '1'
option fw_mask '00ff0000'
option ipv6_enabled '0'
option nft_rule_counter '0'
option nft_set_auto_merge '1'
option nft_set_counter '0'
option nft_set_flags_interval '1'
option nft_set_flags_timeout '0'
option nft_set_policy 'performance'
option nft_user_set_counter '0'
option procd_boot_trigger_delay '5000'
option procd_reload_delay '0'
option resolver_set 'none'
option strict_enforcement '1'
option uplink_interface 'wan'
option uplink_interface6 'wan6'
option uplink_ip_rules_priority '30000'
option uplink_mark '00010000'
option verbosity '2'
list ignored_interface 'vpnserver'
list lan_device 'br-lan'
list resolver_instance '*'
list webui_supported_protocol 'all'
list webui_supported_protocol 'tcp'
list webui_supported_protocol 'udp'
list webui_supported_protocol 'tcp udp'
list webui_supported_protocol 'icmp'
option config_compat '25'
option config_version '1.2.2-r14'
option rule_create_option 'add'
option webui_show_ignore_target '0'
list supported_interface 'WgWappingCl'
config include
option path '/usr/share/pbr/pbr.user.dnsprefetch'
option enabled '0'
config include
option path '/usr/share/pbr/pbr.user.aws'
option enabled '0'
config include
option path '/usr/share/pbr/pbr.user.netflix'
option enabled '0'
config dns_policy
option name 'Redirect Local IP DNS'
option src_addr '192.168.1.5'
option dest_dns '1.1.1.1'
option enabled '0'
config policy
option name 'Ignore Local Requests'
option interface 'ignore'
option dest_addr '10.0.0.0/24 10.0.1.0/24 192.168.100.0/24 192.168.1.0/24'
option enabled '0'
config policy
option name 'Plex/Emby Local Server'
option interface 'wan'
option src_port '8096 8920 32400'
option enabled '0'
config policy
option name 'Plex/Emby Remote Servers'
option interface 'wan'
option dest_addr 'plex.tv my.plexapp.com emby.media app.emby.media tv.emby.media'
option enabled '0'
config policy
option name 'WappingLAN'
option dest_addr '192.168.5.0/24'
option interface 'WgWappingCl'
Routing table displayed in LUCI
Routing
The following rules are currently active on this system.
I would really apprecaite any input that anyone can provide on where I might be going wrong getting the local traffic to route across the VPN. As you can see I haven't just added the remote subnets as allowed IPs on the VPN because I want to be able to eventually send any remote IP (including public IP traffic across to the other router to deliver externaly via its gateway)
Should I be seeing the PBR rules being added to the routing status data I can see in LUCI?
Lets have a look at your current setup also from the "server" side:
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
Remember to redact keys, passwords, MAC addresses and any public IP addresses you may have but do not redact private RFC 1918 IP addresses (192.168.X.X, 10.X.X.X and 172.16-32.X.X) as that is not needed:
"Client" side
service pbr support
ifconfig
ip route show table all
ip -6 route show table all
"Server" side"
ubus call system board
cat /etc/config/network
cat /etc/config/firewall
ip route show
wg show
default via 192.168.0.1 dev wan table pbr_wan
default via 10.7.254.11 dev WgWappingCl table pbr_WgWappingCl
default via 192.168.0.1 dev wan proto static src 192.168.0.51
10.7.0.1 via 192.168.0.1 dev wan proto static
10.7.254.0/24 dev WgWappingCl proto kernel scope link src 10.7.254.11
10.11.0.0/24 dev br-lan proto kernel scope link src 10.11.0.1
192.168.0.0/24 dev wan proto kernel scope link src 192.168.0.51
local 10.7.254.11 dev WgWappingCl table local proto kernel scope host src 10.7.254.11
broadcast 10.7.254.255 dev WgWappingCl table local proto kernel scope link src 10.7.254.11
local 10.11.0.1 dev br-lan table local proto kernel scope host src 10.11.0.1
broadcast 10.11.0.255 dev br-lan table local proto kernel scope link src 10.11.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 192.168.0.51 dev wan table local proto kernel scope host src 192.168.0.51
broadcast 192.168.0.255 dev wan table local proto kernel scope link src 192.168.0.51
fd9f:7397:e719::/64 dev br-lan proto static metric 1024 pref medium
unreachable fd9f:7397:e719::/48 dev lo proto static metric 2147483647 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev wan proto kernel metric 256 pref medium
fe80::/64 dev br-lan proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
anycast fd9f:7397:e719:: dev br-lan table local proto kernel metric 0 pref medium
local fd9f:7397:e719::1 dev br-lan table local proto kernel metric 0 pref medium
anycast fe80:: dev eth0 table local proto kernel metric 0 pref medium
anycast fe80:: dev wan table local proto kernel metric 0 pref medium
anycast fe80:: dev br-lan table local proto kernel metric 0 pref medium
local fe80::3224:78ff:fed8:1fa8 dev eth0 table local proto kernel metric 0 pref medium
local fe80::3224:78ff:fed8:1fa8 dev br-lan table local proto kernel metric 0 pref medium
local fe80::3224:78ff:fed8:1fac dev wan table local proto kernel metric 0 pref medium
multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev br-lan table local proto kernel metric 256 pref medium
multicast ff00::/8 dev wan table local proto kernel metric 256 pref medium
multicast ff00::/8 dev WgWappingCl table local proto kernel metric 256 pref medium
fd9f:7397:e719::/64 dev br-lan proto static metric 1024 pref medium unreachable fd9f:7397:e719::/48 dev lo proto static metric 2147483647 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium fe80::/64 dev wan proto kernel metric 256 pref medium fe80::/64 dev br-lan proto kernel metric 256 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium anycast fd9f:7397:e719:: dev br-lan table local proto kernel metric 0 pref medium local fd9f:7397:e719::1 dev br-lan table local proto kernel metric 0 pref medium anycast fe80:: dev eth0 table local proto kernel metric 0 pref medium anycast fe80:: dev wan table local proto kernel metric 0 pref medium anycast fe80:: dev br-lan table local proto kernel metric 0 pref medium local fe80::3224:78ff:fed8:1fa8 dev eth0 table local proto kernel metric 0 pref medium local fe80::3224:78ff:fed8:1fa8 dev br-lan table local proto kernel metric 0 pref medium local fe80::3224:78ff:fed8:1fac dev wan table local proto kernel metric 0 pref medium multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium multicast ff00::/8 dev br-lan table local proto kernel metric 256 pref medium multicast ff00::/8 dev wan table local proto kernel metric 256 pref medium multicast ff00::/8 dev WgWappingCl table local proto kernel metric 256 pref medium
The server side is a bit of a hot mess. Its been around for a while as my daily driver openwrt router - I was trying to use this test router to get things straight and learn on the 'client' side first i.e getting the routing to go the right way etc. before looking at the sever side of things (where I will no doubt distrupt things)
Having said that the only particulary unusual thing is that my wireguard server (with the endpoint) has multiple peers - but that doesn't seem to cause any issues with traffic transiting the tunnel - and I haven't configured anything in terms of routing on the interface on the server end (except that the hosts for the interface are routed (I haven't put no-route-hosts) on the interface and given it an IP of 10.7.254.1/24 on the interface
If that is your only objective i.e. have access to the other side the you do not need PBR.
Such a setup is referred to as a site-to-site setup see the guide.
Basically instead of 0.0.0.0/0 on the peer you add the subnet of the other side in this case it looks like 192.168.5.0/24 and then Enable Route Allowed IPs
That is all because then a route is made to route all traffic for 192.168.5.0/24 via the tunnel
Your client setup looks OK, only deviation is that you do not masquerade the vpn traffic that is actually fine for a site-to-site setup as then the server side will have the client side subnet as allowed IPs but this is probably not yet the case here so you should either masquerade the VPN traffic or make a decent site-to-site setup (recommended)
From my reading of those extracts there is no route being added to 192.168.5.0/24 but you are saying that I shouldn't see that when displaying routes using the route command or via LUCI?
Would the configuration of the Interface as supported when it doesn't have a endpoint cause an issue?
Can you see anything on the clientside that isn't right? I've read throught the docs and maybe I'm just missing something obvious on the client side?
Sorry for being so verbose but from the 'client router' what I am seeing is that a traceroute goes directly out via the client's wan (In this case that is 192.168.0.1) - then on to my actual public facing internet connection router - rather than heading towards the VPN.
traceroute to 192.168.5.1 (192.168.5.1), 20 hops max, 46 byte packets
1 192.168.0.1 1.461 ms
2 10.53.39.121 10.180 ms
3 *
4
So the lan -> wan forward is masquaded. (its just going to a 192.168.0/24 address because its double natted to get out to the internet)
I'm just trying to get the extracts for the 'server' side - there is a bit more to go through.. I'll also pull wg show for the client. (sorry missed that)
Yeah the wireguard is not masqurading /NATing - my thought that it should all be routing inside the lan zone (which covers the wireguard interfaces and LAN)
Client: Wg show
interface: WgWappingCl
public key:
private key: (hidden)
listening port: 34781
peer:
endpoint: 10.7.0.1:51720
allowed ips: 0.0.0.0/0, ::/0
transfer: 0 B received, 123.57 KiB sent
persistent keepalive: every 25 seconds
So pasting this last wg_show i've realised at some point the connection dropped. - I realised that between the two boxes I was actually travering the public IP endpoint and back in so i've updated this so the two routers server and client connect directly across the 192.168.0.0/24 subnet on my border router by pointing directly to the server's end point rathe than the port forwarded endpoint available publically.
interface: WgWappingCl
public key: <REDACTED>
private key: (hidden)
listening port: 56823
peer: <REDACTED>
endpoint: 192.168.0.24:51820
allowed ips: 0.0.0.0/0, ::/0
latest handshake: 1 minute, 15 seconds ago
transfer: 707.63 KiB received, 721.30 KiB sent
persistent keepalive: every 25 seconds
Why this address it is also in the WG subnet that will not going to work.
On the WG server you have a lot of peers with 0.0.0.0/0, overlapping peers will lead to undetermined behaviour
That is not the way to route via a WG interface so remove it and add the route to the allowed IPs of the corresponding peer that is how a site-to-site setup works please see the appropriate section in the guides
On the client side add to the allowed IPs 192.168.5.0/24 and also the WG subnet 10.7.254.0/24 if you want other peers of that server to have access. Remove 0.0.0.0/0 and :/0 and Enable Route Allowed IPs
But you are correct there is definitely room for improvement of your setup
