Enabling NAT Acceleration (CTF) breaks Port Forwarding? (RT-AC68U w/ 386.12_4)

[Mr Solis]

Hi,

I've come across an issue with port forwarding not working when IPTraffic is disabled. My intention was to enable CTF to increase throughput.

EDIT1: Ahh, further research shows NAT acceleration and port forwarding are incompatible.

EDIT2: Why is it that port forwarding for TCP works, but not for UDP?

 

[RandomUser777]

I have port forwarding with udp and tcp, and NAT acceleration enabled. No problems.

 

[Tech9]

No problems.

Is your router model RT-AC68U running 386 firmware?

 

[RandomUser777]

Is your router model RT-AC68U running 386 firmware?

My current one is an AX86U-Pro.

But when still used my AC68U (several months ago) on 386, I had the same port forwarding as now, and everything worked fine.

 

[ColinTaylor]

EDIT2: Why is it that port forwarding for TCP works, but not for UDP?

How are you testing this?

 

[Tech9]

In theory NAT acceleration is disabled for the traffic on forwarded ports only, but I remember in reality RT-AC68U had issues.

I never tested this hardware with Asuswrt-Merlin 386.12_4 though and don't know how it works on this specific firmware version.

 

[Mr Solis]

How are you testing this?

I recently upgraded to FTTP 1gbps. I previously had QoS enabled when I was on 100mbps so everything was running fine until i disabled QoS and IPTraffic in order to enable NAT acceleration and CTF to increase throughput (max 915mbps which is impressive on this antique!)

I run services that require UDP ports to be forwarded. However, since enabling CTF, these UDP ports are no longer publicly accessible . My TCP ports are still forwarding as expected.

• I host a few game servers such as Valheim and Palworld which require UDP port forwarding.
• Web UI services that require TCP port forwarding are working fine.

I've also performed a factory reset and set everything up from scratch with the same outcome. I've also used online tools for port checking; TCP is reporting fine but UDP is a no go.

This is the output for nvram show | grep ctf

size: ctf_disable=0
ctf_disable_force=0
ctf_fa_cap=0
ctf_nonat_force=0
ctf_pt_udp=0
54434 bytes (11102 left)

It's a real bummer because I would prefer not to have to replace the RT-AC68U. It's been a fine workhorse.

 

[ColinTaylor]

I host a few game servers such as Valheim and Palworld which require UDP port forwarding.

There is a known bug in this situation that effects UDP connections via NAT loopback from within your LAN. But this should not effect connections that are originating from the internet. I didn't have a problem with my RT-AC68U but there are a couple of different hardware versions of that router that handle CTF differently IIRC.

 

[ColinTaylor]

This is the output for nvram show | grep ctf

size: ctf_disable=0
ctf_disable_force=0
ctf_fa_cap=0
ctf_nonat_force=0
ctf_pt_udp=0
54434 bytes (11102 left)

Try this:

nvram set ctf_pt_udp=1
nvram commit
service restart_firewall

 

[Mr Solis]

Try this:

nvram set ctf_pt_udp=1
nvram commit
service restart_firewall

No bueno unfortunately.

 

[ColinTaylor]

No bueno unfortunately.

Post the output of this command, there should be a UDP rule.

iptables-save -t mangle

 

[Mr Solis]

Post the output of this command, there should be a UDP rule.

iptables-save -t mangle

Sure thing.

ASUSWRT-Merlin RT-AC68U 386.12_4 Wed Nov 22 03:36:28 UTC 2023
User@RT-AC68U:/tmp/home/root# iptables-save -t mangle
# Generated by iptables-save v1.4.15 on Sat Jan 27 13:12:58 2024
*mangle
:PREROUTING ACCEPT [374704:428117218]
:INPUT ACCEPT [360594:425487018]
:FORWARD ACCEPT [13979:2610002]
:OUTPUT ACCEPT [254353:72707752]
:POSTROUTING ACCEPT [268342:75330910]
-A FORWARD -s 192.168.1.0/24 -d 192.168.1.0/24 -o br0 -j MARK --set-xmark 0x1/0x7
-A FORWARD -p udp -m state --state NEW -j MARK --set-xmark 0x1/0x7
COMMIT
# Completed on Sat Jan 27 13:12:58 2024

 

[ColinTaylor]

That looks correct. I'm out of ideas. You could try entering this command but I doubt it will make a difference.

iptables -t mangle -A PREROUTING -p udp -m state --state NEW -j MARK --set-mark 0x1/0x7

 

[Mr Solis]

That looks correct. I'm out of ideas. You could try entering this command but I doubt it will make a difference.

iptables -t mangle -A PREROUTING -p udp -m state --state NEW -j MARK --set-mark 0x1/0x7

No luck either

Don't know if this is of any significance but i am still able to connect to my OpenVPN server via UDP 1194, but I'm assuming that's because i'm connecting directly to the router where NAT isn't required.

 

[NGRhodes]

In theory NAT acceleration is disabled for the traffic on forwarded ports only, but I remember in reality RT-AC68U had issues.

I never tested this hardware with Asuswrt-Merlin 386.12_4 though and don't know how it works on this specific firmware version.

NAT is not used (rather than acceleration disabled) for forwarded ports as there is no need to map external to internal IP/ports (like with NAT). Fowarded ports have little CPU overhead (in the context of SOHO routers), not worth accelerating. Should be no noticeable performance loss using forwarded ports compared to accelerated NAT.

 

[Tech9]

NAT is not used

And how is an IPv4 server with private LAN IP going to get through public WAN IP with no NAT?

 

[NGRhodes]

And how is an IPv4 server with private LAN IP going to get through public WAN IP with no NAT?

Port forwarding is for incoming connections on defined port. Servers wait/listen for incoming connections.
Applications that run as servers may also establish outgoing connections, which may use a different port (which would use NAT) or use the forwarded port.
You can't port forward and use NAT at the same time on the same port.
NAT (port based as on most SOHO routers) is not that dissimilar to port forwarding, but NAT has to lookup and track far more information.
With NAT, the src/dst port needs to be looked up to find the src/dst IP for each packet (and then applied to each packet), these translations need to be stored in a lookup table, were as with port forwarding you have a single variable to access and modify each packet header with, not 65000 possibilities which need to be looked up and applied each time.

There is an article https://www.smallnetbuilder.com/lan...to-find-the-best-router-for-gigabit-internet/ which tests CTF with port forwarding enabled and it shows they are compatible.
RMerlin himself states in the discussion for the article (https://www.snbforums.com/threads/how-to-find-the-best-router-for-gigabit-internet.38635/) port forwarding is able to work with CTF enabled (not just port forwarding bypassing CTF). "Your results would indicate that there would still be some acceleration in place even when a packet goes through a port forward. Maybe Broadcom improved their CTF implementation over the years."
Thiggins from the same link "The tests show that port forwarding does NOT reduce throughput, with the possible exception of one case".
If CTF and port forwarding are not working together here, its due to a quirk/bug, not because they are incompatible.

 

[ColinTaylor]

Port forwarding is for incoming connections on defined port. Servers wait/listen for incoming connections.
Applications that run as servers may also establish outgoing connections, which may use a different port (which would use NAT) or use the forwarded port.
You can't port forward and use NAT at the same time on the same port.
NAT (port based as on most SOHO routers) is not that dissimilar to port forwarding, but NAT has to lookup and track far more information.
With NAT, the src/dst port needs to be looked up to find the src/dst IP for each packet (and then applied to each packet), these translations need to be stored in a lookup table, were as with port forwarding you have a single variable to access and modify each packet header with, not 65000 possibilities which need to be looked up and applied each time.

I think there might be some difference in terminology here. NAT is applied to connections originating from the internet and "port forwarded" to a LAN server, as well as connections originating from a LAN client to a server on the internet. In the first case the destination address in NATed, in the second case it's the source address. This can be seen by looking at the iptables rules where you'll see -j DNAT for port forwarding rules and -j MASQUERADE (as special form of SNAT) for outgoing connections. Active connections established in both directions can be seen in the conntrack table.

There is an article https://www.smallnetbuilder.com/lan...to-find-the-best-router-for-gigabit-internet/ which tests CTF with port forwarding enabled and it shows they are compatible.
RMerlin himself states in the discussion for the article (https://www.snbforums.com/threads/how-to-find-the-best-router-for-gigabit-internet.38635/) port forwarding is able to work with CTF enabled (not just port forwarding bypassing CTF). "Your results would indicate that there would still be some acceleration in place even when a packet goes through a port forward. Maybe Broadcom improved their CTF implementation over the years."
Thiggins from the same link "The tests show that port forwarding does NOT reduce throughput, with the possible exception of one case".
If CTF and port forwarding are not working together here, its due to a quirk/bug, not because they are incompatible.

That article is talking only about TCP, which works with CTF to achieve near gigabit throughput. The specific problem the OP has here is with UDP connections, which are not compatible with CTF and are therefore not hardware-accelerated (or at least that used to be the case in the past). There is actually an iptables rule (see post #12) that was specifically used for UDP which marks the packet so that it bypasses CTF.

With all that said, the router's CTF module has undergone various changes over the years. Whether it's currently working correctly I have no idea. Maybe they fixed the UDP problem, or maybe they broke it completely. For such an old router I doubt Asus/Broadcom will spend any time trying to fix any problems.