For the security of the server, we often modify the commonly used server port. In IPv4, you can use iptables -t nat -i prerouting -i pppoe-wan -p tcp --dport 10022 -j DNAT --to-destination 10.0.0.1: 22 Such rules perform port forwarding to realize different ports inside and outside the application, so how to use ip6tables in the PPPoE IPv6-PD SLAAC mode environment to achieve similar functions.
In this case you have a public IPv6 in the lan. If you install the nat6 packages you could rewrite the port on the ip6tables. But this is anyway security through obscurity.
Assuming you have a reason, why you need the port translation, I see two ways to go about this:
-
The pragmatic route: Configure an ULA prefix so your client has a stable address. Then use NAT6, as @trendy mentioned, to implement the port forwarding in a similar fashion you did for IPv4.
-
The clean way: Update your ip6tables rule whenever your public prefix changes. For other DHCPv6 clients on common Linux distributions, I've written small hook scripts to to similar things whenever the prefix changes. I assume you can hook in to odhcpd as well and add a custom script to achieve this, but as I never needed it on OpenWrt, I can't provide any more details regarding the implementation.
Well, it depends on the use case. With port translation you can do things like reaching multiple devices with the same destination port behind your firewall. So, port 10022 gets forwarded to port 22 on server A, while port 10023 gets forwarded to port 22 on server B, for instance. With IPv6 alone, there's no need for this, but with IPv4 and private addresses behind your firewall, this can be useful if you can't simply change the default ports on the target machine.
In addition, you can simply reduce the noise in the logs if you run your server on a non-standard port which is something I usually appreciate because it helps you focus on the more meaningful log messages.
Run two ssh servers on the machine, allow only the custom port on OpenWrt firewall.
1 Like
This is cool. Good to know! 
This is why I wrote "Assuming you have a reason, why you need the port translation". If you have full control over the machines and applications you're dealing with, then it's certainly easier to simply change the ports on the targets. But if if you're dealing, for example, with two commercial devices where you simply can't change the ports, then you might resort to solutions such as port translation. Not that I would ever want to expose the SSH service on a proprietary device/firmware on the public internet, but I'm just saying sometimes simpler solutions aren't always feasible.
1 Like
Modifying the service port directly is a helpless move. I think the best way is to make the internal network port different from the public network port, so that the internal network can be accessed using common ports.