iptables - Cannot traceroute from container behind NAT if SMTP port forwarding set in host

Question

I've created a fairly simple port forwarding rule to redirect requests to port 25 to a specific container in the virtual environment:

iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to 10.10.10.4

The forwarding appears to be working. When I access it from the outside world via telnet, I can reach the destination mail server:

 telnet mail.mydomain.tld 25
 Trying 1.2.3.4...
 Connected to mail.mydomain.tld.
 Escape character is '^]'.
 220 mail.mydomain.tld ESMTP Postfix (Ubuntu)
 quit
 221 2.0.0 Bye

However, when I run a traceroute to Gmail from within the destination container where Postfix is running, it leads nowhere. The end result is that all non-local mail delivery gets deferred with a 4.3.0 DSN code.

When i delete the aforementioned iptables port forwarding rule from the PREROUTING chain, traceroute hops all the way to the destination IP.

This is th exact traceroute command I'm using:

traceroute -n -T -p 25 gmail-smtp-in.l.google.com

My best guess is that I am missing some rule in the INPUT chain. But if this were the case, i don't understand why telneting from the outside would work.

Right now I do not have any rules in the INPUT chain (don't actually remember ever needing any in this particular environment).

I've read somewhere that adding the rule below could address the issue, but I haven0t tried yet, lest it have some nefarious consequence. This is a production environment after all.

iptables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Answer 1

I've created a fairly simple port forwarding rule to redirect requests to port 25 to a specific container in the virtual environment:

iptables -t nat -A PREROUTING -p tcp --dport 25 -j DNAT --to 10.10.10.4

It's actually too simple to work correctly: it will intercept any port 25 destination... including connections from the container to the outside world which are redirected back to the container. Typically the container's network stack will see its own IP address incoming from outside, sent from its own IP address to its own IP address and will drop it (no NAT hairpin done) which is better than if it could work: if SMTP's configuration allowed such request, the server in the container would loop back to itself trying to route the email but would never reach anything else than itself.

Add an additional filter that prevents this. It could be per-interface or per-address and depends on your layout and intents. From the question's available information, adding an exception for the container's IP itself might be enough. Instead of the initial rule use:

iptables -t nat -A PREROUTING ! -s 10.10.10.4 -p tcp --dport 25 -j DNAT --to 10.10.10.4

This will still intercept correctly routed SMTP traffic sent to the host and send it to the container instead, but the container's SMTP server will now be able to forward such emails by reaching the next SMTP server correctly. This won't work for the host itself (nat/OUTPUT should be used). If you have problems for the host itself or need the host's queries to also be intercepted, this will need additional settings.