After some digging in the GPL sources, I found that in /etc/config/nat, section 'rule_napt' the IP was set to 0.0.0.0. This means that *ALL* traffic is going to be NATed, regardless.

So, I managed to gain root access to my ER605 and changed 0.0.0.0 to 192.168.0.0/16 and re-applied the config; lo and behold my normal LAN is still NATed and my public IPs are just routed. Happy days!

So, if somebody from TP-Link reads this, would you kindly change the ranges to be NATed by default to only include the ranges specified in rfc1918 or make it configurable?

Thanks!

Sjon

  @Clive_A Thank you for your reply!

Clive_A wrote

Hi @Sjon_Gerrits 

1. There is no way that you can disable the NAT.

2. We don't offer any root access. Nor provide any docs to do so.

3. Do you access these IPs even you don't own them??

Sjon_Gerrits wrote

- I can ping hosts inside the /29 from the public internet and can connect to them without issues

 4. How do you determine that by saying "appear"? How do you monitor it? Can you illustrate your test methodology?

Sjon_Gerrits wrote

- HOWEVER, all connections initiated from the /29 subnet hosts appear as coming from the /32 main IP. Of course, this should not be happening.

1. I just found out his is a bug/issue in the ER605's firmware concerning only PPPoE-connections, I will make a separate post further down.

2. The internet does ;) You too will probably know what the 'debug' command does in the 'remote assistance'-console and how those passwords are generated

3. I do not 'own' them, they were allocated/leased to me by my ISP. So it's nothing illegal or shady. It is fully supported by them (just not by that many routers these days).

4. I test it by initiating connections from from those IPs. Sites like test-ipv6[.]com also work. They will show the /32 not their actual IP

For example, an SSH connection:

Without changing the NAT rules:

Last login: Wed Aug 16 07:24:40 2023 from xx.xx.5.201 (my /32)

After changing 'postrouting_rule_multinat' from -s 0.0.0.0 (again, this appears to be a bug) to -s 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 (as it should be!)

Last login: Wed Aug 16 07:24:45 2023 from xx.xx.171.134 (from my /29 network)

And both LANs still have connectivity.

  @d0ugmac1 

Thank you for your suggestion, it is a PPPoE connection, and the web interface doesn't allow me to add the subnet as 'virtual' or 'alias' IPs; this only works with setting the connection type to Dynamic/Static IP.

On the other hand, in my opinion, public addresses should just be routed/firewalled, not NATed.

@Clive_A 

From what I can tell, at least in the case of a PPPoE-connection, the script /lib/nat/nat_napt.sh builds the masquerading rules using information from /etc/config/nat.

Option 'ipaddr' and 'mask' under 'rule_napt' are of interest. Since they where 0.0.0.0 and 0, this meant that all IPv4-traffc from the (v)lans was going to be masqueraded; resulting in the issue I had where incoming connections worked fine, but outgoing traffic was always masqueraded.

Luckily, files in /etc/config are saved across reboots, so I changed ipaddr and mask to 192.168.0.0 and respectively and restarted the device. Now the masquerading rules are constructed correctly.

I still think this is an issue that should be fixed; only non-routable IP-space specified in RFC1918 should be masqueraded. This is a business router afterall...

Again, thanks for the replies and I hope this information is useful Please let me know if you need more information.

Sjon

  @Sjon_Gerrits 

Thank you for your suggestion, it is a PPPoE connection, and the web interface doesn't allow me to add the subnet as 'virtual' or 'alias' IPs; this only works with setting the connection type to Dynamic/Static IP.

Are you saying that its not possible to specify the additional public subnet as a Secondary (static) connection on the WAN when the main connection type is PPPoE ?

  @MisterW 

As it currently stands, that is not possible, no. The 'secondary connection' for PPPoE appears to be for something else. 

But since the 'WAN IP Alias' seems to be a new feature, it will probably be added in the future.