for the purpose of getting to some cameras and routers etc.
plus a few similar rules, at that (20.20.20.2) router for destination nat and everything is fine on it.
Then,
Since that time, it became necessary to introduce NAT in the path to 10.4.2.210 at 10.251.250.6 to put that group out on their own public IP, a large group including where I was NAT ing to.
I’m getting lost in the IP obfuscations in your post…
Could you throw a quick diagram on this, and use a.a.a.X for ips on public network A, b.b.b.X for public network B, etc, just so it’s easier to keep track of what’s a public IP and what’s a private IP?
Taking a stab at this anyway, though…
It kind of makes sense that the original destination should get broken because you’re creating (I think) an asymmetric route when using the older mapping. Probably what’s happening is the 10.4.2.210 device is properly forwarding the requests to the cameras, but then either the cameras use a different default GW now (the device that’s 10.251.250.6 on its wan) or else 10.4.2.210 has some other default GW than your NAT router with 20.20.20.33 on the WAN… probably the former guess.
If this is the case, then probably you should add a masquerade rule to the 10.4.2.210 router when forwarding the old pinholes toward the actual camera LAN, which will make the cameras think it’s that router who’s connecting to them and they’ll reply to its IP address, which will get de-nat-xlated back to the old 10.4.2.210 address which will then go back out and get de-nat-xlated back to 20.20.20.33
If it’s 10.4.2.210 which has a new default GW which isn’t the router with 20.20.20.33 on it, then you should add a masquerade in the router with the 20.20.20.33 public IP on packets whose destination IP is 10.4.2.210
wait local-to-local IP communication? never use NAT for those - use routing.
Also add in-interface=public to your original dst-nat rules, and place them in the begging of dst-nat chain. Assuming that your routing is configured correctly , this should ensure that your dst-nat rules are working always.
Netmap is to map one network to another, so it is for address-range to same size address-range thing, not 1 IP like you shown.
OK the purpose is not enough Pub IPs for all clients, sometimes it is desirable to track back and assign a public IP to certain inside addresses.
I can accomplish this anywhere on the inside of the NAT pretty quickly with Netmap, as it allows a way to hop over several routers directly to where I want and assign a Pub IP that a subnet or user router will be visibly coming out on. The down side, is the problem I queried about. Maybe not the best solution, but can be implemented quickly. You can’t do it twice, as far as I can see, so the issue becomes this:
I changed some of the numbers from the original (hopefully) for clarity.
Also I expected the answer that it should be routed, not NAT’d. and that may be the only solution, but not the solution I am looking for now.
I think the issue is called NAT traversal? I am posting this as an image to hold the layout.
This may have become as much an exercise of stubborn curiosity as anything…