Wireguard: make remote LAN reachable from a local LAN

Hello. A networking noob here.

I have the following setup:

My LAN is the "WG Server" side in the picture (i.e. on the right). The tunnel b/w the client and the server is up and running and both the peers can see/ping each other as well as corresponding LANs (i.e. 10.0.1.1 -> 192.168.220.0, 10.0.1.2 -> 192.168.1.1) - tested by ssh-ing into my router and pinging "from within".

The question is: how do I make the remote LAN on the "client" side reachable not only "from within" my router, but also from devices in my LAN (192.168.1.1/24)?

I've tried adding a route like this:

route add 192.168.220.0 mask 255.255.255.0 10.0.1.1 (as well as 192.168.1.1)

But it didn't work - hosts in the 192.168.220.0/24 network are still unreachable from my LAN.

Let's take a look at the following files from each 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:
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

There you go:

root@archer_c7:~# ubus call system board
{
        "kernel": "5.10.176",
        "hostname": "archer_c7",
        "system": "Qualcomm Atheros QCA9558 ver 1 rev 0",
        "model": "TP-Link Archer C7 v2",
        "board_name": "tplink,archer-c7-v2",
        "rootfs_type": "squashfs",
        "release": {
                "distribution": "OpenWrt",
                "version": "22.03.4",
                "revision": "r20123-38ccc47687",
                "target": "ath79/generic",
                "description": "OpenWrt 22.03.4 r20123-38ccc47687"
        }
}
root@archer_c7:~# 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 'fdb2:c1d2:e0cb::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth1.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        list dns '1.1.1.1'
        list dns '8.8.8.8'

config interface 'wan'
        option proto 'dhcp'
        option peerdns '0'
        list dns '1.1.1.1'
        list dns '8.8.8.8'
        option device 'eth0.201'

config interface 'wan6'
        option proto '6rd'
        option peeraddr '205.171.2.64'
        option ip6prefix '2602::'
        option ip6prefixlen '24'
        option ttl '255'
        option mtu '1480'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '0t 2 3 4 5'

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option vid '201'
        option ports '6t 1t'

config interface 'wg0'
        option proto 'wireguard'
        option private_key '<REDACTED>'
        option listen_port '51888'
        list addresses '10.0.1.1/24'

config wireguard_wg0
        option description 'Samsung A71'
        option public_key '<REDACTED>'
        list allowed_ips '10.0.0.2/32'
        option route_allowed_ips '1'

config wireguard_wg0
        option description 'network-share'
        option route_allowed_ips '1'
        option public_key '<REDACTED>'
        list allowed_ips '192.168.220.0/24'
        list allowed_ips '10.0.1.2'
        list allowed_ips '192.168.100.2/32'
root@archer_c7:~# cat /etc/config/firewall

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

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

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option masq '1'
        option mtu_fix '1'
        option input 'REJECT'
        option forward 'REJECT'
        option output 'ACCEPT'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        list proto 'icmp'
        option src 'wan'
        option target 'DROP'
        option name 'all-ping'
        option dest 'lan'
        option enabled '0'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config rule 'wg'
        option name 'Allow-WireGuard'
        option src 'wan'
        option dest_port '51888'
        option proto 'udp'
        option target 'ACCEPT'

It looks like you posted the public IP side that is listening for inbound connection requests, correct?

While not related to the issue at hand...

you should upgrade to 22.03.6 at the minimum. Consider upgrading to 23.05.2 since that is the most current.

We need to edit the network-share peer stanza... 10.0.1.2 should be specified as /32, and the other allowed IPs should be removed. It will look like this:

config wireguard_wg0
        option description 'network-share'
        option route_allowed_ips '1'
        option public_key '<REDACTED>'
        list allowed_ips '10.0.1.2/32'

Next, we'll add a route for 192.168.220.0/24 via 10.0.1.2

config route
	option interface 'wg0'
	option target '192.168.220.0/24'
	option gateway '10.0.1.2'

Can you post the other side's config files?

1 Like

Yes, correct.

Yeah, thanks for noticing. When flashing I somehow picked not the most recent version :blush:

Will fix.

The other (the "client") side is not an OpenWRT device. It's a Keenetic KN-1811. I can access ssh on that device, I just don't know what would be the needed equivalent commands for that device.. sorry.

Well, the firewall on that device (if any) could potentially be an issue, but let's at least see the wireguard config details.

In a site to site peer configuration, allowed_ips is the /32 of the peer (the other side) and the full network of any LANs on the other side. Do not have any local IPs in allowed_ips.

Set the route_allowed_ips flag to install routes to the other LAN(s) automatically. It is then not necessary to add any routes.

Placing the wg network in the lan zone allows unrestricted forwarding between the LANs, which is what you want at least initially.

3 Likes

Here is the "client"''s config.

:+1: Got it.

That's exactly the way it was set up.

If I understood this correctly, that part has also been set up like you said from the very beginning:
image

Delete all of the allowed IPs from here, and then add 192.168.1.0/24. You can also put in 10.0.1.0/24, but I don't think that's required here.

Done.

Also, when I removed the "client"-side network (192.168.220.0) from the AllowedIPs (from the Peer section of the "server") and added a static route you mentioned above:

config route
	option interface 'wg0'
	option target '192.168.220.0/24'
	option gateway '10.0.1.2'

My router (the "server") could no longer ping the "client". So I reverted it back - deleted the static route and added 192.168.220.0/24 entry on the server's AllowedIPs list.

Still can't ping the client LAN (192.168.220.0/24) from devices in the server's LAN (192.168.1.0/24) :slight_smile:

It is possible that the remote side (i.e. the one with the CG-NAT address) needs some additional configuration in the routing table and/or firewall.

Also, if you're dealing with any windows based hosts, they will, by default, not respond to connection requests or pings from a different subnet. You must change the firewall settings on Windows to allow that to work.

Meanwhile, are you able to test the ability for the 192.168.220.0/24 network to reach the 192.168.1.0/24 network?

My desktop PC in the picture (192.168.1.36) runs Windows. Remote ("client" side) hosts are non-Windows.

Just logged into the router device (the WG client that hosts the 10.0.1.2/24 interface) and tried pinging the "server" router at 192.168.1.1. No response.. even though the address is on the AllowedIPs list:

None of the devices in the 192.168.220.0/24 network are currently available to me to log in and try pinging.

P.S. The "server's" end of the tunnel (10.0.1.1) pings fine from the client router.

UPDATE: I don't know if it's of any help, I did ip route on the "client" side. Here are the results:

/ # ip route
default dev ppp0 scope link
1.1.1.1 dev ppp0 scope link
10.0.1.0/24 dev nwg2 scope link  src 10.0.1.2
97.113.41.45 dev ppp0 scope link
100.115.128.1 dev ppp0 scope link  src 100.115.152.245
192.168.100.0/24 dev eth3 scope link  src 192.168.100.2
192.168.220.0/24 dev br0 scope link  src 192.168.220.0
192.168.221.0/24 dev br2 scope link  src 192.168.221.1
192.168.222.0/24 dev br3 scope link  src 192.168.222.1

It doesn't look like 192.168.1.1 entry is there at all)

Agreed. And that means the traffic may not be able to return.

You'll need to figure out the configuration of that side of the tunnel in order to make this work.

1 Like

What I did on the "client" (10.0.1.2) side of the tunnel is:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 0.0.0.0 dev nwg2

for the routing to work back to the "server" (10.0.1.1). After that client->server pings started to go through just fine.

Also, from devices in my LAN (192.168.1.1) I am now able to reach devices in the LAN on the client side of the tunnel (192.168.220.0). I am assuming this happened automatically - since my router (192.168.1.1) now has end-to-end back-and-forth connectivity with the "client" LAN, it advertises itself as a router responsible for routing to those destinations and hosts in my LAN just pick it up. Am I correct here?

P.S. Gentlemen, @psherman @mk24 thank you very much for your guidance and suggestions through this! In the end of this "exercise" the fog in my head around WG & networking cleared up a bit! :slight_smile:

Awesome, glad it is all working now!!

1 Like

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