I know firewall NAT action NETMAP is an 1:1 address mapping based on to-addresses netmask, I expected action SAME would be more flexible, but seems like it doesn’t or I am facing a bug or issue here.
I want to NAT an address list with ~1k addresses to a /22 public IP subnet for just outgoing Internet access. The address list is filled with random addresses from ~200 mixed RFC1918 network ranges, like 10.90.0.0/24, 10.0.2.0/24, 172.31.110.0/24… really mixed. Public IP subnet is like 198.51.100.0/22.
NAT is not working for some addresses, 10.90.0.17 for instance and many other, which are just ignored. It seems like SAME is behaving exacly as NETMAP and trying an 1:1 match on host parts of both address list and to-addresses’ addresses. It takes 10.90.0.17/22 and looks for 198.51.0.17 on to-addresses subnet but can’t find it.
Is SAME expected to behave like that? If so, what’s the difference between SAME and NETMAP and how do you suggest I could get mapping working as expected, please?
I suspect of a bug because I’m sure it was working fine for months with a simple rule with just out-interface, action=same, same-not-by-dst=yes and to-addresses=198.51.100.0/22 (no src-address or src-address-list), but now even this simple rule doesn’t work without those issues anymore.
Running RouterOS 6.46.8 on a CCR1009-7G-1C-1S+. Nothing even nearly related to this in changelogs for newer versions. Already tried a reboot… Nothing else had been changed beyond firewall NAT rules while trying to accomplish this holy mapping. There is nothing else on firewall filter, NAT, mangle neither raw.
same - gives a particular client the same source/destination IP address from supplied range for each connection. This is most frequently used for services that expect the same client address for multiple connections from the same client
This tells me nothing regarding SAME logic, wether it is supposed to work just like NETMAP in the way it maps source and destination addresses or not.
I’m not sure if my issue is SAME performing matches the same way as NETMAP. Did a test with /24 subnet in to-addresses and it was supposed 10.90.0.17 to be mapped as 198.51.100.17 when to-addresses=198.51.100.0/24, but it isn’t, it just doesn’t work. If to-addresses is set to a subnet equal or smaller than /25 it works for 10.90.0.17 and every address I checked (despite addresses ending in 129 or greater being mapped to “last octet - 128” in case of /25, for instance).
Actually, testing with /25 and smaller subnets showed me SAME won’t work for me as it will eventually repeat addresses from to-addresses but I need unique public source addresses (can I get some advice on getting this accomplished?).
Netmap - Maps IPs 1:1, so must be 1000 IPs to 1000IPs, i.e. a /22 to a /22
Same - You might have 1000 IPs mapping to 255 IPs, so the NAT will try and use the same NAT IP map per src/dst address pair, if src and or dst is different, it might use another IP to map/NAT to
My understanding as well, however SAME lefts some IP addresses with no NAT like if it ignores them when having /24 or larger subnets in to-addresses (/25 and smaller works fine). It seems buggy or works in another way.
Is the simple action=same rule you’ve mentioned above the only one in chain srcnat of /ip firewall nat? Are there any rules in /ip firewall raw?
NAT is a functionality of connection tracking, so packets matching an action=notrack rule in /ip firewall raw cannot be NATed at all.
Also the “simple action=same rule” may be shadowed by some preceding rule in chain srcnat, matching packets whose source address doesn’t get changed by the action=same rule.
Yes, when testing that was the only action=same rule in srcnat chain. Actually the only IP/Firewall/NAT rule. Nothing in IP/Firewall/Raw, Filter or Mangle.
You are correct, that it behaves identical to netmap, netmap originally was 1:1, but some point in the Linux Kernel chanelogs (I do not know the version number), netmap supported 1:Many.
Netmap/Same simply ensures the same ExternalIP:Port mapping when possible for the same clientIP:Port combination.