Port Forwarding Over WireGuard Connection?

[HarryMuscle]

I'm trying to add iptables rules to forward a port over my WireGuard client connection to a machine on the LAN. If I run a WireGuard client directly on the machine in question the port is forwarded, however, doing so through the router is proving difficult. Here are the rules I've added:

iptables -t nat -A PREROUTING -p tcp -i wgc1 --dport 12345 -j DNAT --to-destination 192.168.50.50:12345
iptables -t nat -A PREROUTING -p udp -i wgc1 --dport 12345 -j DNAT --to-destination 192.168.50.50:12345

According to the counters these rules are getting executed by there's nothing reaching the 192.168.50.50 machine. I also tried adding these rules based on the suggestion from https://www.snbforums.com/threads/port-forwarding-on-wireguard-seems-unsupported-in-388-1.83486:

iptables -I FORWARD -p tcp -d 192.168.50.50 --dport 12345 -m state --state NEW -j ACCEPT
iptables -I FORWARD -p udp -d 192.168.50.50 --dport 12345 -m state --state NEW -j ACCEPT

Also 192.168.50.50 is listed in VPN Director and routed through WGC1 and the machine accesses the internet via the VPN connection. But still https://www.yougetsignal.com/tools/open-ports/ reports that the port is closed.

Any suggestions on what to try next?

Thanks,
Harry

 

[ZebMcKayhan]

I also tried adding these rules based on the suggestion from https://www.snbforums.com/threads/port-forwarding-on-wireguard-seems-unsupported-in-388-1.83486:

iptables -I FORWARD -p tcp -d 192.168.50.50 --dport 12345 -m state --state NEW -j ACCEPT
iptables -I FORWARD -p udp -d 192.168.50.50 --dport 12345 -m state --state NEW -j ACCEPT

Are the forward rules getting the same hit count as the prerouting rule?

 

[HarryMuscle]

Are the forward rules getting the same hit count as the prerouting rule?

I must have looked at the counters only for the PREROUTING rules cause those are going up, however, the rules in the FORWARD chain are are 0 so they are clearly not getting executed. Any idea what the issue might be with those?

Thanks,
Harry

 

[ZebMcKayhan]

Any idea what the issue might be with those?

As you are not changing port, try to skip the port in prerouting rule, such as

iptables -t nat -A PREROUTING -p tcp -i wgc1 --dport 12345 -j DNAT --to-destination 192.168.50.50
iptables -t nat -A PREROUTING -p udp -i wgc1 --dport 12345 -j DNAT --to-destination 192.168.50.50

 

[HarryMuscle]

As you are not changing port, try to skip the port in prerouting rule, such as

iptables -t nat -A PREROUTING -p tcp -i wgc1 --dport 12345 -j DNAT --to-destination 192.168.50.50
iptables -t nat -A PREROUTING -p udp -i wgc1 --dport 12345 -j DNAT --to-destination 192.168.50.50

No difference. The PREROUTING rules still get executed like before and the FORWARD chain rules still have counters of 0 meaning they aren't getting executed at all.

Looking through the iptables rules I don't see anything that would be rejecting the packets before getting to the FORWARD rules but I'm not an iptables expert.

 

[ZebMcKayhan]

No difference. The PREROUTING rules still get executed like before and the FORWARD chain rules still have counters of 0 meaning they aren't getting executed at all.

Looking through the iptables rules I don't see anything that would be rejecting the packets before getting to the FORWARD rules but I'm not an iptables expert.

And you are 100% sure that 192.168.50.50 is set to use wgc1 by vpndirector, and the rule is active? If not, the reverse path filtering will block the packet before reaching FORWARD chain.

 

[HarryMuscle]

And you are 100% sure that 192.168.50.50 is set to use wgc1 by vpndirector, and the rule is active? If not, the reverse path filtering will block the packet before reaching FORWARD chain.

Yes. I've double checked by going to mylocation.com in a browser on the 192.168.50.50 machine to check which IP I'm browsing the web with and it matches the VPN location selected. But is there a way to check the counters on the reverse path filtering rule to see if it's getting executed none the less?

Thanks,
Harry

 

[ZebMcKayhan]

But is there a way to check the counters on the reverse path filtering rule to see if it's getting executed none the less?

Not that I know of, but you could disable it and see if you get hits on your forward rule:

echo 0 > /proc/sys/net/ipv4/conf/wgc1/rp_filter

 

[ZebMcKayhan]

But is there a way to check the counters on the reverse path filtering rule to see if it's getting executed none the less?

Ooh, looks like Dropped packets could be logged to syslog by

echo 1 >/proc/sys/net/ipv4/conf/wgc1/log_martians

But I have never tested it...

 

[HarryMuscle]

Not that I know of, but you could disable it and see if you get hits on your forward rule:

echo 0 > /proc/sys/net/ipv4/conf/wgc1/rp_filter

Yup, that's the culprit somehow. As soon as I disable the rp_filter as you suggested the FORWARD chain rule counter started to increase whenever I tested if the port was open via https://www.yougetsignal.com/tools/open-ports/. But I've double and tripple checked that the 192.168.50.50 IP is in VPN Director routed through WGC1. Any idea what could be causing this?

Thanks,
Harry

 

[HarryMuscle]

Ooh, looks like Dropped packets could be logged to syslog by

echo 1 >/proc/sys/net/ipv4/conf/wgc1/log_martians

But I have never tested it...

Interesting, now I get these in my syslog:

Nov  5 16:36:41 kernel: IPv4: martian source 192.168.50.50 from xxx.xxx.xxx.244, on dev wgc1

where xxx.xxx.xxx.244 is close to my VPN public IP address but not quite. Mine is xxx.xxx.xxx.245. Obviously there is some routing going on on the VPN server where externally it's .245 but the data gets sent to the tunnel from .244. Maybe that's the issue?

 

[ZebMcKayhan]

Interesting, now I get these in my syslog:

Nov  5 16:36:41 kernel: IPv4: martian source 192.168.50.50 from xxx.xxx.xxx.244, on dev wgc1

where xxx.xxx.xxx.244 is close to my VPN public IP address but not quite. Mine is xxx.xxx.xxx.245. Obviously there is some routing going on on the VPN server where externally it's .245 but the data gets sent to the tunnel from .244. Maybe that's the issue?

What do you get from:

ip route get xxx.xxx.xxx.244 from 192.168.50.50 iif br0

 

[HarryMuscle]

What do you get from:

ip route get xxx.xxx.xxx.244 from 192.168.50.50 iif br0

I get

xxx.xxx.xxx.244 from 192.168.50.50 via yyy.yyy.yyy.yyy dev eth0 table wgc4
    cache iif br0

where yyy.yyy.yyy.yyy is the gateway for my WAN connection.

Thanks,
Harry

 

[HarryMuscle]

I get

xxx.xxx.xxx.244 from 192.168.50.50 via yyy.yyy.yyy.yyy dev eth0 table wgc4
    cache iif br0

where yyy.yyy.yyy.yyy is the gateway for my WAN connection.

Thanks,
Harry

But using my actual .245 IP address for the ip route statement I get

xxx.xxx.xxx.xxx from 192.168.50.50 dev wgc4 table wgc4
    cache iif br0

 

[HarryMuscle]

So I read you can set the return path filter to loose filtering by setting it to 2 (echo 2 > /proc/sys/net/ipv4/conf/wgc1/rp_filter) which just like disabling the filter allows the FORWARD chain rules to actually get executed, but strangely enough I still don't get the packet fowarded correctly cause the https://www.yougetsignal.com/tools/open-ports/ site still tells me the port is closed. So there's something else at play here too.

 

[ZebMcKayhan]

So I read you can set the return path filter to loose filtering by setting it to 2 (echo 2 > /proc/sys/net/ipv4/conf/wgc1/rp_filter) which just like disabling the filter allows the FORWARD chain rules to actually get executed, but strangely enough I still don't get the packet fowarded correctly cause the https://www.yougetsignal.com/tools/open-ports/ site still tells me the port is closed. So there's something else at play here too.

You have a route in table wgc4 that sends everything to xxx.xxx.xxx.244 to eth0 (wan). That's why it's not working.

Why is this route put there? It wouldn't happen to be your wgcX endpoint ip? Then fw adds this route to make sure wg tunnel is going out wan. However it's usefulness in table wgc4 is questionable.

If you find the route and why it's there you could try to remove it... then everything should be working.

 

[HarryMuscle]

You have a route in table wgc4 that sends everything to xxx.xxx.xxx.244 to eth0 (wan). That's why it's not working.

Why is this route put there? It wouldn't happen to be your wgcX endpoint ip? Then fw adds this route to make sure wg tunnel is going out wan. However it's usefulness in table wgc4 is questionable.

If you find the route and why it's there you could try to remove it... then everything should be working.

My endpoint in configured via a hostname but I wouldn't be surprised if that's what it resolves to (I'm not at a computer to check at the moment). I didn't add any routes to anything so it must be the firmware doing that. Wouldn't removing that route break the connection to the WireGuard server though?

Thanks,
Harry

 

[ZebMcKayhan]

My endpoint in configured via a hostname but I wouldn't be surprised if that's what it resolves to (I'm not at a computer to check at the moment).

Ok... check what's being used by

wg show

Check all wgc Interface.

Wouldn't removing that route break the connection to the WireGuard server though?

Typically no... the router will not use any br0 ip unless you have explicitly told it so, or if it's trying to send packets to br0. So it won't be affected by your vpndirector rule. It will typically use main routing table only. Exception is if you make vpndirector rules based on destination ip only.
If this an wg endpoint ip you should be fine by removing it from wgc4 route table.

No better way then to test and see.

 

[HarryMuscle]

Ok... check what's being used by

wg show

Check all wgc Interface.



Typically no... the router will not use any br0 ip unless you have explicitly told it so, or if it's trying to send packets to br0. So it won't be affected by your vpndirector rule. It will typically use main routing table only. Exception is if you make vpndirector rules based on destination ip only.
If this an wg endpoint ip you should be fine by removing it from wgc4 route table.

No better way then to test and see.

Sounds good. Thanks so much for your help. I'll let you know once I get a chance to try this out.

 

[HarryMuscle]

Ok... check what's being used by

wg show

Check all wgc Interface.



Typically no... the router will not use any br0 ip unless you have explicitly told it so, or if it's trying to send packets to br0. So it won't be affected by your vpndirector rule. It will typically use main routing table only. Exception is if you make vpndirector rules based on destination ip only.
If this an wg endpoint ip you should be fine by removing it from wgc4 route table.

No better way then to test and see.

Sure enough that's the issue. Strange though cause rules pointing to the endpoint are present in all of the other WireGuard clients' route tables also so it's definately something the firmware adds. I wonder if this route is something new in 388.4 cause the few other posts about port forwarding via WireGuard haven't come across this issue yet but they are older threads so chances are they were using an older firmware version. Anyway for anyone coming accros this, here's the command needed to make the rules in my first post work:

ip route del xxx.xxx.xxx.xxx table wgcX

where xxx.xxx.xxx.xxx is the IP address of the WireGuard endpoint and the wgcX is the correct wireguard client (ie: wgc1, wgc2, etc.)