Do source ports matter?

Quick context: my ISP gives me a publicly routable IP, but blocks inbound packets on a few known privileged ports, like TCP 80 and TCP 443, on their “residential” plans, so to speak (for both security and commercial reasons, of course). I haven’t done a full diagnostics on every port over TCP and UDP, but the one affecting me the most is UDP 123 (which causes problems for NTP clients on Windows and RouterOS).

Given that, my NAT rules look something like this right now:


/ip firewall nat add action=masquerade chain=srcnat out-interface-list=wan-interface-list protocol=udp src-port=123 to-ports=49152-65535
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=wan-interface-list
/ipv6 firewall nat add action=src-nat chain=srcnat out-interface-list=wan-interface-list protocol=udp src-port=123 to-ports=49152-65535

Now, this seems to solve all problems that meet the eye. There may be some other application using source ports in the privileged range, but none causing any visible problems at the moment. (In the past, I did put some monitoring rules and I saw at least one case where an IoT device randomly used a source port 7xx over TCP, but I don’t remember observing any issues and that port probably was not blocked anyway)

Now here’s my main question: do source ports matter? Can’t I make all my NAT rules use source ports 1024-65535 and stop worrying about any other possible problems that might arise due to blocking on known privileged ports? Don’t CGNAT implementations already do this anyway? What is considered good practice regarding this? What if I do the following?


/ip firewall nat add action=masquerade chain=srcnat out-interface-list=wan-interface-list protocol=tcp to-ports=1024-65535
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=wan-interface-list protocol=udp to-ports=1024-65535
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=wan-interface-list
/ipv6 firewall nat add action=src-nat chain=srcnat out-interface-list=wan-interface-list protocol=tcp to-ports=1024-65535
/ipv6 firewall nat add action=src-nat chain=srcnat out-interface-list=wan-interface-list protocol=udp to-ports=1024-65535

Generally source ports don’t matter … unless they do. As you found out, some ISPs block some well known ports and UDP 123 is often one of them (it used to be abused by some DDoS amplification attacks), UDP 53 is another one. Vast majority services, which are accepting connections at well known ports, use (normal) random high-numbered ports when they initiate egress connection themselves. One notable exception is NTP service, which (in most implementations, not only in ROS implementation) uses same privileged port 123 when starting egress connections.

Also: generally ROS, when doing SRC NAT, keeps port numbers unaltered unless this collides with existing (NATed) connection … which (given randomly chosen source port) doesn’t happen too often. And since apps are required to choose random high port (1024+ by definition, more often 10000+), configuring SRC NAT machinery for mapping everything into high port numbers shouldn’t be necessary. Except for exceptions :wink: