Is my port forwarding with WireGuard working properly or?

[Deleted member 83610]

I have set up a WireGuard connection with port forwarding on my Asus RT-AX86U (with the latest Asuswrt-Merlin firmware). Everything seems to be working great...

This is my iptables FORWARD table:

As you can see marked in green above the iptables firewall is letting through a ton of packets coming in on WireGuard Client 5/WGC5.

However, my PREROUTING table rules doesn't get hit at all unless I manually test that port forwarding is working (from you get signal):

Isn't that weird?

This is my POSTROUTING table by the way:

VPN Director has automatically created the rule marked in green above to handle the traffic the other way.

 

[ZebMcKayhan]

Isn't that weird?

Sure is...

Ive read somwhere that not all packets are hitting the nat tables. Perhaps only some packets (like initial packets) hits here the rest are offloaded to some autonomous function deep inside netfilter to replicate for related packets, thus not counted?
Or this could be an effect of FlowCache (nat hw accelleration) perhaps?

Ill be interested to know as well.

Worth notice is the main deviation are for udp packets.

 

[Deleted member 83610]

Flow Cache is on:

Not sure I want to try and turn it off.

I'm wondering if this has something to do with VPN Director?

Also just found my iptables PREROUTING rules in the GUI:

Is there perhaps some other iptables chain I should be using when using VPN Director and WireGuard?

Port Fowarding and Port Trigger is disabled by the way as I understood this is for WAN only (which is under the tab where they are found as well):

 

[ZebMcKayhan]

I'm wondering if this has something to do with VPN Director?

No way, VPNDirector handles routing and some firewall rules only. Your rules are on top so higher priority than anything else.

Is there perhaps some other iptables chain I should be using when using VPN Director and WireGuard?

No, you are using the only possible ones. Sure the firmware is creating own chains and call them from these, but its just a matter of flavor / tidyness.

Port Fowarding and Port Trigger is disabled by the way as I understood this is for WAN only (which is under the tab where they are found as well):

Not sure what this does, probably creates the custom chain and calls it from prerouting. But it may be empty if you havnt added any. Turn it on and check for yourself.

 

[Deleted member 83610]

I finally had some time to do some more testing:

• Turning on Port Forwarding under WAN made no difference to the hits of my rules in the iptables PREROUTING chain.
  
  
• Switching from WireGuard back to OpenVPN made no difference to the hits of my rules in the iptables PREROUTING chain.
  
  
• I use ProtonVPN and turning On/Off Moderate NAT made no difference to the hits of my rules in the iptables PREROUTING chain:
  
  
  
  
  
  
  

I'm of course selecting P2P servers marked with this symbol:

NAT is by default enabled in the WireGuard client on the Asus router:

NAT-PMP is also working fine on the router:

As I saw the the NAT-PMP screenshot above... Is NAT-PMP the reason why my rules in the iptables PREROUTING chain are ignored?

 

[ZebMcKayhan]

As I saw the the NAT-PMP screenshot above... Is NAT-PMP the reason why my rules in the iptables PREROUTING chain are ignored?

That would explain the udp difference atleast, but natpmp goes over port 5351 (?). But perhaps related packets?

If you have Entware installed you could install TcpDump which should be able to capture the packets to see what it is?

 

[Deleted member 83610]

I do have Entware installed, but it's been a while since I last used tcpdump and WireShark.

With ProtonVPN the natpmp client gets a random remote port mapped to the same port locally (symmetrical NAT):

This got me thinking: How does clients out there on Internet know about which remote port the natpmp client has opened on my Asus router?

I figured I had to match this port in the client I'm using so it's announced to others out there. That was it!

Finally my rules in the iptables PREROUTING chain get hit as they should (and not just when I manually test from CanYouSeeMe.org):

 

[ZebMcKayhan]

I do have Entware installed, but it's been a while since I last used tcpdump and WireShark.

With ProtonVPN the natpmp client gets a random remote port mapped to the same port locally (symmetrical NAT):

View attachment 53303

This got me thinking: How does clients out there on Internet know about which remote port the natpmp client has opened on my Asus router?

I figured I had to match this port in the client I'm using so it's announced to others out there. That was it!

Finally my rules in the iptables PREROUTING chain get hit as they should (and not just when I manually test from CanYouSeeMe.org):

View attachment 53305

So, any idea about why this manifested in the way that it did? Your rules are kindof picky so in PREROUTING any packet recieved on WGC5 dport 61373 is DNAT to 192.168.1.110:53560
Then in FORWARD matches only packets from WGC5 destination 192.168.1.110 dport 53560.
So what packets would hit the FORWARD chain without hitting the PREROUTING chain?? Are there packets from WGC5 with 192.168.1.110:53560 as destination already without DNAT??

 

[Deleted member 83610]

My TCP rule in the iptables PREROUTING chain only got hit when I manually checked if the forwarded port actually was open with something like you get signal. Problem was no one else out there on the Internet knew about my forwarded port (which was the key to solving the issue).

I believe my rules in the FORWARD chain still got hit because that port was specified and accepted by my client software and connections were initiated the other way, that is from my client to others on the Internet (and then back through my iptables firewall openings).

 

[ZebMcKayhan]

that port was specified and accepted by my client software and connections were initiated the other way,

Ofcource, if you local clients connects/announce port 53560 outbound to wgc5, adress translation would be done via MASQUARADE and conntrack so your DNAT rule would never be hit because of wrong port but as everything matches for the FORWARD rule it will match. It would normally hit by the RELATED, ESTABLISHED rule but your rule would be higher up and take priority. Brilliant!

 

[privacyguy123]

I use ProtonVPN Wireguard from within the router also and have attempted to forward it via the UI (which I am beginning to understand is unsupported) yet I can't see the port they provide me via NAT-PMP open at all ever no matter what I do on that open port checker website ... what am I missing

EDIT: Some deeper hacking by adding firewall rules and nat rules allows forwarding to work with a OPVN/WireGuard connection on. It seems counterintuitive to even have a port forwarding UI element if it doesn't apply to these connections for some reason ... Perhaps someone could write a script that installs over the in built UI to improve it.