Wireguard VPN only works one way

Got a really weird issue I can't figure out. Got a Wireguard site-to-site tunnel set up between a Aerohive BR200WP (Running 23.05 RC3 - this is the first major release supporting this platform) and a Aerohive AP330 (running 22.03.5). The tunnel works, everything is authenticated but the issue is that I can't connect to the remote network using the BR200. got a few Aerohive AP330 set up as dumb AP on the remove network and they are able to access the main network. (So the VPN is working). From the main network, I'm able to access everything on the remote network, including the BR200. Seems to be a routing issue but I'm unable to figure out what it might be, as everything should be flowing correctly.

High level topology Remote network (192.168.55.1/24) - BR200WP - Wireguard - AP330 - Main network (172.22.40.0/22)

Routes from the BR200 (Remote network)

root@BR200WP-SR:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         209-169-157-1.m 0.0.0.0         UG    0      0        0 wan
100.64.43.0     *               255.255.255.252 U     0      0        0 wg0
142.113.20.211  209-169-157-1.m 255.255.255.255 UGH   0      0        0 wan
172.22.40.0     *               255.255.252.0   U     0      0        0 wg0
192.168.55.0    *               255.255.255.0   U     0      0        0 br-lan
209.169.157.0   *               255.255.255.128 U     0      0        0 wan

Routes from the AP330 (Main Network)

root@AP330-PPPoE-Backup:~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.11.16.113    0.0.0.0         UG    0      0        0 pppoe-wan
10.11.16.113    *               255.255.255.255 UH    0      0        0 pppoe-wan
100.64.43.0     *               255.255.255.252 U     0      0        0 wg0
172.22.40.0     *               255.255.252.0   U     0      0        0 br-lan
192.168.55.0    *               255.255.255.0   U     0      0        0 wg0
209.169.157.73  10.11.16.113    255.255.255.255 UGH   0      0        0 pppoe-wan

Ping from 172.22.43.33 to 192.168.55.1 (BR200 IP)

ping 192.168.55.1
PING 192.168.55.1 (192.168.55.1) 56(84) bytes of data.
64 bytes from 192.168.55.1: icmp_seq=1 ttl=63 time=12.9 ms

Ping from 192.168.55.1 (BR200) to 172.22.43.33

ping 172.22.43.33
PING 172.22.43.33 (172.22.43.33): 56 data bytes
^C
--- 172.22.43.33 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

Ping from a dumb AP on remote network (192.168.55.3) to 172.22.43.33

ping 172.22.43.33

PING 172.22.43.33 (172.22.43.33): 56 data bytes
64 bytes from 172.22.43.33: seq=0 ttl=61 time=10.637 ms
64 bytes from 172.22.43.33: seq=1 ttl=61 time=11.440 ms
64 bytes from 172.22.43.33: seq=2 ttl=61 time=10.300 ms

Unsure what's going on. Unless it's a bug in the RC3 (Same behaviour was observed on RC2)

Any wild ideas?

Welcome to the community!

Please remember to use codeboxs for output.

Screenshot_20230905-125101_Samsung Internet

What are the firewall settings?

2 Likes

For symmetric routing to work, Masquerade must not be set on the firewall zone that contains the wg0 interface-- on either end. And a pair of forward rules must be in place to cover both directions: lan to VPN and VPN to lan.

I assume that both of these boxes are the main routers in their respective networks. If not, there are additional concerns to get packets routed through a LAN device "appendage" VPN server.

Thanks for the replies. Will use the codebox. Apologies for the output.

For the Masquerade part, it's should be Ok. I thoroughly made sure that firewall rules are in place to cover the LAN to VPN and VPN to LAN traffic, on both ends.

However, I may have done something odd.

As for the firewall rules:

Firewall rules on remote (BR200)

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

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

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

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

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'
	option 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-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'
	option enabled '0'

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

config rule
	option name 'Allow Inbound SSH'
	option family 'ipv4'
	list proto 'tcp'
	option src 'wan'
	option target 'ACCEPT'
	option dest_port '22'

config zone
	option name 'wg0'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'wg0'
	option family 'ipv4'

config forwarding
	option src 'wg0'
	option dest 'lan'

config forwarding
	option src 'wg0'
	option dest 'wan'

config forwarding
	option src 'lan'
	option dest 'wg0'

config forwarding
	option src 'wan'
	option dest 'wg0'

config rule
	option name 'wan-local-wg-s2s'
	option family 'ipv4'
	list proto 'udp'
	option src 'wan'
	option dest_port '41820'
	option target 'ACCEPT'

Firewall rules on central site (AP330)

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

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

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

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

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'
	option 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-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'
	option family 'ipv4'
	option enabled '0'

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

config rule
	option name 'Allow SSH'
	option family 'ipv4'
	list proto 'tcp'
	option src 'wan'
	option target 'ACCEPT'
	option dest_port '22'

config zone
	option name 'WG'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option family 'ipv4'
	list network 'wg0'

config forwarding
	option src 'WG'
	option dest 'lan'

config forwarding
	option src 'WG'
	option dest 'wan'

config forwarding
	option src 'lan'
	option dest 'WG'

config forwarding
	option src 'wan'
	option dest 'WG'

config rule
	option family 'ipv4'
	list proto 'udp'
	option src 'wan'
	option dest_port '41820'
	option target 'ACCEPT'
	option name 'wan-local-wg-s2s'

Make that ACCEPT

Furthermore note that clients you are trying to reach can have their own firewall.

As a test if this is the problem you can enable MASQUERADE on the lan zone

1 Like

Moving from REJECT to ACCEPT does not change anything unfortunately (Through it would have been logical to assume so)

Maybe a high level view of the issue I'm facing.

For reference, I put a syslog server as a target. Ping works per my table, but also assume that SSH and syslog works too. No firewall is active on the target (172.22.43.5).

As you can see, the VPN itself works fine both way. But the remote router, acting as the VPN endpoint, simply cannot connect to the 172.22.40.0/22 LAN.

Also, I might add this. On the remote Router (192.168.55.1), I can ping the inside interface of the central site router (172.22.43.0).

I'd start with tcpdump -i wg0 icmp, tcpdump -i br-lan icmp and tcpdump -i wan icmp on both routers in paralle and run that ping you started with again. This will tell you how far the ping request comes and if it maybe even reaches its destination. There's a chance its the return path for the response package which isn't good.

1 Like

What operating system is on the syslog server host? Does it have a local firewall? is that enabled or disabled?

When you originate a connection through the VPN from the router, the router's wireguard IP is used as the source address. In a point to point system, this is the only time that the wireguard tunnel itself needs to hold an IP address.

You're using a /30 netmask on the tunnel itself, which means that the two ends of the tunnel must be exactly 100.64.43.1/30 and 100.64.43.2/30. The other two IPs in a /30 (.0 and .3 in this case) are reserved. The allowed_ips must be set up to allow the other side of the tunnel's 100 IP.

That's already verified.

Thanks for the reply through!

Will do the packet capture to see what's up.Good idea

Perhaps also show output of
cat /etc/config/network
and post it here using the "Preformatted text </> " button:

1 Like

Well, we can close this one down. There was a slight issue with the routes on my main router on the main site. Somehow, I forgot to put the route for the 100.64.43.0/30 network.

ip route 100.64.43.0 255.255.255.252 172.22.43.0 and boom, problem solved.

Again, thanks to everyone who took the time to solve the issue. I knew it was something trivial and stupid, but I could not pinpoint it. Thanks to @egc for making me look at the network config, it made me realize the issue.

Great you solved it but with a proper setup you do not have to set extra routes.
The routes are set by the Allowed IP's and then enabling route Allowed IPs

Oh and if you make the WG interface with /24 netmask you will have an automatic route of the WG subnet otherwise add the IP address of the WG interface of the other side to the allowed IPs (besides the subnets of the other side for proper routing).

1 Like

I did not include the rest of the network, that is far more complex. (That AP330, is really a backup WAN connection for my main network, and I use it for a S2S tunnel between 2 locations. The main network and all the routing runs on Cisco hardware. But in the end, some small details are important. You helped in that regard!

Thanks again!

1 Like

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