I am experience a routing problem where an ICMP request comes in to a wireguard server but the response is routed to the main gateway not back to wg0.
I am using an MT300Nv2 as a VPN server. I want to be able to access the Mango’s LAN through wireguard. I can ping the mango itself, but get no response when pinging any host on the mango’s LAN.
In order to save ports, I reconfigured the mango so that the WAN port is tagged and carries both LAN and WAN traffic. WAN traffic is on VLAN1 (eth0.1) and LAN traffic is on VLAN5 (eth0.5).
Using tcpdump on the mango and the upstream router, I find that the ICMP requests do arrive properly over wg0. If I ping the mango from a host connected via wireguard, the ICMP reply DOES go back to wg0 and the ping is successful. However, if I ping any other host on the mango’s LAN, I see the ICMP request come in over wg0 but the ICMP echo reply is sent to the upstream router (WAN gateway) and NOT back to wg0.
Setup:
Wireguard is on 10.89.5.x. Wireguard client assigned 10.89.5.4.
LAN is 10.86.5.x
WAN is 10.86.1.x
Upstream (main) router is multi-homed at 10.86.1.1 and 10.86.5.1.
Mango router LAN is 10.86.5.2 and is assigned a static WAN 10.86.1.4 address.
Machines on the LAN all have the mango (10.86.5.2) as their gateway.
Tracing:
-
Wireguard client (10.89.5.4) sends ICMP Echo Request to 10.86.5.20 (host on the mango LAN)
-
Mango receives request on wg0 and forwards to LAN (eth0.5)
-
Mango receives response from LAN (eth0.5).
-
Mango FORWARDS RESOPNSE TO UPSTREAM ROUTER (eth0.1) NOT wg0!
Of course, the main router has no idea what to do with a 10.89.x.x address as it cannot forward to the internet and certainly won’t forward back to the mango to return via wireguard.
Here’s the request coming into, but not returning to wg0:
tcpdump: listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
11:20:23.345625 ip: (tos 0x0, ttl 64, id 49542, offset 0, flags [none], proto ICMP (1), length 84)
10.89.5.4 > 10.86.5.157: ICMP echo request, id 43840, seq 0, length 64
Here’s the traffic on the mango LAN (eth0.5). We can see the request going out and the reply coming back:
tcpdump: listening on eth0.5, link-type EN10MB (Ethernet), capture size 262144 bytes
11:52:42.805539 e4:95:6e:45:b5:2c > 50:e5:49:ce:69:e6, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 31350, offset 0, flags [none], proto ICMP (1), length 84)
10.89.5.4 > 10.86.5.157: ICMP echo request, id 49728, seq 0, length 64
11:52:42.808871 50:e5:49:ce:69:e6 > e4:95:6e:45:b5:2c, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 55848, offset 0, flags [none], proto ICMP (1), length 84)
10.86.5.157 > 10.89.5.4: ICMP echo reply, id 49728, seq 0, length 64
Here’s the “funny” part… Here’s the traffic on the WAN (eth0.1) interface:
tcpdump: listening on eth0.1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:56:03.734323 e4:95:6e:45:b5:2c > 6c:b0:ce:30:0a:9f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 24615, offset 0, flags [none], proto ICMP (1), length 84)
10.86.5.157 > 10.89.5.4: ICMP echo reply, id 51520, seq 0, length 64
[Note: I had to run multiple pings, so this traffic is not a single ping, but the same pattern holds over and over.]
The mango’s routing table looks fine:
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.86.1.1 0.0.0.0 UG 10 0 0 eth0.1
10.86.1.0 * 255.255.255.0 U 10 0 0 eth0.1
10.86.5.0 * 255.255.255.0 U 0 0 0 br-lan
10.89.5.0 * 255.255.255.0 U 0 0 0 wg0
I’ve uploaded a printout of my IPTABLES and the network configuration file.MangoWireguardRouting.zip (4.5 KB)
Where is this going wrong?
Any way to trace why replies destined for an address on the wg0 interface are being sent out on the WAN interface instead?
I try to avoid it as much as possible…