On 02/03/2017 11:04 AM, Brian Bostwick wrote:
Thanks for the help! I realized that my goal is not attainable because
I do not have control over the initial connection. I believe your
suggestion would work if that weren't the case.
However, I came across this picture, which seems misleading. It is an
example of how not to use NAT, which is admittedly what I am doing,
but it suggests I can change the destination. Can anyone confirm that
it is just meant as an illustration of why this scenario is improper?
http://inai.de/images/dnat-mistake.png
What the picture shows is DNAT of the destination IP address. What you
are trying to do is DNAT/DNPT of only the destination port.
In the picture, the original packet goes to the DNAT host but the reply
packet goes directly to the source host which prevents the DNAT host
from translating it back.
In your case, the *original* packet goes directly to the destination
host and the DNAT host has nothing to say about it at all.
You can actually fix the case in the picture by adding the SNAT rule.
Then the traffic would look like this:
original packet:
src 1.3.3.7:1111 dst 1.3.3.8:2222 -> src 1.3.3.8:3333 dst 1.3.3.9:2222
reply packet:
src 1.3.3.9:2222 dst 1.3.3.8:3333 -> src 1.3.3.8:2222 dst 1.3.3.7:1111
Which is hideous and causes 1.3.3.9 to see the peer's IP as 1.3.3.8
instead of 1.3.3.7, but the traffic actually gets there.
In your case there is nothing you can do from the DNAT host because it
never even sees the packets.
The thing you could do is to change that. Put the source and destination
hosts in different subnets so they always have to go through the router.
Then you would only need the DNAT rule and both would see the correct IP
addresses.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
