Hi @JeKeWa 

Thanks for posting in our business forum.

JeKeWa wrote

  @Clive_A 

 

I'm actually pretty good with this stuff, having worked on IP routing since I operated an ISP in the 1990s with Bay Networks (long gone) routers. I've continued providing networking configurations and security to many companies since. I choose this kind of budget equipment only for my home network, because I shouldn't really need more for my few nodes, and don't even have enough need to just dedicate a workstation or server to the task. I specifically chose this router because I thought it was a real wired router, unburdened with WiFi. So much of its management and the things in this forum indicate that it is really intended to be a NAT proxy instead.

 

In my post, as recommended in the directions, I obfuscated my IPs by using 10s, which I know are not Internet routable. Hopefully you didn't take my use of the private network addressing as a reason this wouldn't work. I like using 10s as it allows a lot of zeroes to make it easy to see where network changes occur, without making things up with algebraic substitutions. At the same time, I have worked in groups large enough to need to use 10 as their LAN addressing, and need to subnet and route traffic on that network, so I would expect this to also work with 10s throughout, as long as somewhere there'd be a NAT proxy to reach the Internet.

 

As I have the real, public IPs in my network, I would expect traffic from my nodes to be able to pass through the router to the Internet, and for nodes on the Internet to reach my nodes, without configuring any port forwarding. After disabling the NAT, I would expect the ER605 to see an IP packet on the LAN with an origin IP from that subnet and a destination IP to the Internet to pass that packet to the WAN, and vice-versa. I was able to use the UI to assign the WAN and LAN interfaces with the appropriate network details, but I was unable to get the routing to behave.

 

As for determining the IPs on my network, I either statically address the nodes, or provide DHCP reservations, as desired or necessary. We're talking about a handful of nodes, intended to provide services (web, mail, SSH) on the Internet. One of the nodes is a WiFi router, providing NAT services to other workstations and devices, so there also was interest in avoiding "double NAT," but with this router in front of, not behind, the other router.
 

My mention of iptables was only to provide context about an example of rules that very simply configure a router to openly perform NAT, such as these:

 

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

 

Really, I'd expect the disable NAT feature to really just take out that first line, and the rest would allow normal routing, assuming eth0 and eth1 are correctly addressed. Of course, with any other port forwarding or restricting rules in place also. In the example, it seems eth0 is the LAN and eth1 is the WAN.

 

Of course, there must be a corresponding IP routing, and not simply IP addressing, so that nodes on the eth0 know to use the router's IP as its gateway to the Internet, and somewhere upstream something knows that the eth0 subnet is routed through the eth1 IP. That, as mentioned, seemed to be correctly configured in the information presented through the UI.

 

As I haven't been able to get the ER605 to expose the public addresses, I've repurposed a differet WiFi router, where I simply disabled the WiFi and NAT, and set the WAN and LAN subnets to the correct public subnets. All the routing behaves as expected and described in my post. Nodes on my public subnet are able to reach the Internet and can be reached by Internet nodes, and the nodes behind my NAT have its subnet IP as their Internet address, as expected.

This can be done. I double-checked this with the dev.

The first line does not matter. It won't affect your purpose described above. We have taken this into consideration and tested it before we release this.

We assume it is your routing issue. More details? Wireshark would be great and straightforward.

Hi @Spanky66

Thanks for posting in our business forum.

Go and use the newer controller firmware.

https://community.tp-link.com/en/business/forum/topic/734414

Please be advised that while the firmware of our device may support certain features, these features will not be operational in controller mode unless the corresponding controller has been updated to match the firmware's capabilities. It is essential to understand that updating the device's firmware alone is insufficient; a compatible update to the controller is also required for full functionality in controller mode.