Wireguard + Port Forwarding = Return Traffic exiting through WAN???
-
Hey everyone,
I'm trying to understand what the hell is going on here. I've been bashing my head for 2 days straight on this.
I want to forward a port for my qbittorrent client, and I seem to be having issues with return traffic.
Qbittorrent is running on a VM behind pfsense, and the port forward works with my ISP IP, so the issue doesn't lie within the end machine.From what it seems to me, the return traffic tries to exit through WAN instead of the wireguard virtual interface, while regular outbound VPN traffic works as it should.
Does anyone have any ideas what could be causing this issue?
In the numbered section below I explained how I configured the VPN and the port forward, and after that I posted snippets of packet captures on the relevant interfaces.
-
VPN is working from inside the network:
-
In the subnet on which the qbittorrent VM resides, I made a firewall rule that routes traffic only from the qbittorrent VM to the AirVPN gateway (AirVPN_hosts is an alias for hosts that I want routed over VPN):
-
Port forward to qbittorrent, I just use the same port on qbittorrent as I was assigned on AirVPN.
-
Which creates the following rule automatically (on the AirVPN interface tied to wireguard):
-
I also added an outbound NAT mapping for all hosts that are in the same subnet as the qbittorrent VM. Only the qbittorrent VM should be routed over VPN (As shown in 2.) - Although it seems this mapping does nothing, everything works the same without it (rather doesn't).
Here's a (redacted) packet capture of the AIRVPN wireguard interface with the port filter I'm trying to forward (12345):
wireguard virtual interface IP: 10.20.30.40
VPN exit IP: 50.60.70.8016:11:02.739452 IP 10.20.30.40.1866 > 50.60.70.80.12345: UDP, length 104 16:11:03.578393 IP 10.20.30.40.56477 > 50.60.70.80.12345: tcp 0 16:11:04.579201 IP 10.20.30.40.56477 > 50.60.70.80.12345: tcp 0 16:11:05.581204 IP 10.20.30.40.48124 > 50.60.70.80.12345: tcp 0 16:11:06.595203 IP 10.20.30.40.48124 > 50.60.70.80.12345: tcp 0 16:11:06.595560 IP 10.20.30.40.56477 > 50.60.70.80.12345: tcp 0 16:11:07.583776 IP 10.20.30.40.1866 > 50.60.70.80.12345: UDP, length 20 16:11:07.584421 IP 10.20.30.40.65218 > 50.60.70.80.12345: tcp 0 16:11:08.611245 IP 10.20.30.40.65218 > 50.60.70.80.12345: tcp 0 16:11:08.611321 IP 10.20.30.40.48124 > 50.60.70.80.12345: tcp 0 16:11:10.627204 IP 10.20.30.40.65218 > 50.60.70.80.12345: tcp 0 16:11:10.851284 IP 10.20.30.40.56477 > 50.60.70.80.12345: tcp 0 16:11:11.589916 IP 10.20.30.40.1866 > 50.60.70.80.12345: UDP, length 20 16:11:12.590962 IP 10.20.30.40.28909 > 50.60.70.80.12345: tcp 0 16:11:12.643203 IP 10.20.30.40.48124 > 50.60.70.80.12345: tcp 0
Doing the same capture on WAN shows that the wireguard virtual IP is trying to go out WAN instead of the VPN exit IP, WTF, WHY?
10:40:26.882403 IP 10.20.30.40.12345 > 188.159.237.246.55708: tcp 0 10:40:34.952699 IP 10.20.30.40.12345 > 188.159.237.246.55708: tcp 0 10:40:44.174485 IP 10.20.30.40.12345 > 142.93.172.65.56518: tcp 0 10:40:45.178277 IP 10.20.30.40.12345 > 142.93.172.65.56518: tcp 0 10:40:46.184785 IP 10.20.30.40.12345 > 142.93.172.65.56518: tcp 0 10:40:47.194791 IP 10.20.30.40.12345 > 142.93.172.65.56518: tcp 0 10:40:47.216824 IP 10.20.30.40.12345 > 34.236.150.82.58444: tcp 0 10:40:48.232710 IP 10.20.30.40.12345 > 34.236.150.82.58444: tcp 0
Here's the capture on the interface within which the qbittorrent VM resides:
qbittorrent VM: 10.0.0.10
VPN exit IP: 50.60.70.80
?: 85.17.225.221 (maybe another exit IP?)16:16:08.934998 IP 10.0.0.10.43959 > 50.60.70.80.12345: UDP, length 20 16:16:11.938915 IP 10.0.0.10.43959 > 50.60.70.80.12345: UDP, length 20 16:16:11.939241 IP 10.0.0.10.43959 > 85.17.225.221.12345: UDP, length 20 16:16:14.941980 IP 10.0.0.10.43959 > 50.60.70.80.12345: UDP, length 20 16:16:17.944860 IP 10.0.0.10.60669 > 50.60.70.80.12345: tcp 0 16:16:18.946734 IP 10.0.0.10.60669 > 50.60.70.80.12345: tcp 0 16:16:20.962945 IP 10.0.0.10.60669 > 50.60.70.80.12345: tcp 0
-
-
Holy f**k.
The problem was an any/any rule in the Wireguard unasigned tunnel firewall rule list. Even though the AirVPN WG interface was assigned, group rules are evaluated first...
Hope this helps someone else as well.
-
Oh man, thank you for this. I've been beating my head for 2 days!