Device/Versions:

• Router: ER605 v2, upgraded from firmware 2.2.6 → 2.3.0

• APs: EAP670, upgraded from 1.0.4 → 1.1.1

• Controller: OC 200 2.0, 5.15.24.21

Summary of Issue:
After upgrading the ER605 to v2.3.0, LAN clients connecting to a server on another LAN subnet no longer show their real source IP. Instead, the server only sees the router’s WAN IP (172.x.x.x) if a port forward is defined.

Steps to Reproduce:

1. Upgrade ER605 v2 from 2.2.6 to 2.3.0.

2. Create two LAN subnets (e.g. 192.168.0.0/24 for clients, 192.168.10.0/24 for servers).

3. Run a simple service like whoami on 192.168.10.2 to report client IPs.

4. From a LAN client (192.168.0.x), connect to the server by its LAN IP.

   • With no port forward: server shows 192.168.0.x (expected).

   • With port forward defined: server shows 172.x.x.x (WAN IP of ER605).

What I Expected:

• LAN→LAN traffic should be routed directly, with client source IP preserved.

• Port forwarding should only affect WAN→LAN traffic.

What Actually Happens:

• LAN→LAN traffic is SNATed to the router’s WAN IP when port forwarding exists.

• This breaks correct client IP visibility and access control.

Diagram (simplified):

Wi-Fi Client (192.168.0.x) ──> ER605 ──> Server (192.168.10.2)
     Reports 192.168.0.x (expected)    OR   Reports 172.x.x.x (wrong, when port forward exists)

Question:

• Is this NAT behavior in 2.3.0 intentional?

• If not, can TP-Link confirm whether this is a bug/regression?

• Is there a way to prevent NAT from being applied to LAN→LAN traffic?