Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to NAT traffic sent to the server's private interface to the loopback (because MySQL bind-address is on and can't be changed but I still need to reach it via the private interface).

-mysql bind-address =
-enabled ip forwarding with sysctl -w net.ipv4.ip_forward=1
-setup iptables as follows (eth0 is the private interface)

-A INPUT -i eth0 -p tcp --dport 3306 -j ACCEPT
-A INPUT -i lo --jump ACCEPT
-A INPUT --match state --state ESTABLISHED,RELATED --jump ACCEPT
-t nat -A PREROUTING -i eth0 -p tcp --port 3306 -j DNAT --to-destination
-t nat -A POSTROUTING -o lo -j SNAT --to-source

-the mysql bind is OK (telnet 3306 works fine)
-ip forwarding is properly enabled (sysctl net.ipv4.ip_forward gives 1)
-connectivity to eth0 on 3306 is fine because when I set the bind-address to the IP owned by eth0 I can connect.

With the bind-address on localhost and the above iptables rules I can't connect to the IP owned by eth0 on 3306: if I run tcpdump -ni any port 3306 I can see the SYN followed by a RST but I have now idea where that RST is coming from since I would expect the SYN to be forwarded to lo with ip as both source and destination.

Q: What am I missing to NAT eth0 to lo on port 3306?

additional info: running ubuntu server 10.04 with iptables v1.4.4

Updated question with use case

-We have several boxes with many services (jetty, tomcat, ldap, mysql) running on localhost

-These services need to run on localhost only and don't need to be accessed on the public interface.

-However we would like our external Nagios server to check them via the private interface

-We don't want to configure those services to listen on public interface for security reasons (although we could block them on the public interface, we believe it's better (i.e. Defense in depth) for those services not to listen on the public IP should something go wrong with the firewall)

-Configuring those services to listen on the loopback AND on the private interface is either not possible or more difficult to implement.


Using a NAT from private to internal interface would offer following benefits:

-easier implementation: we don't have to reconfigure existing services

-less maintenance: if new services get added to listen on the loopback, we only need to add iptable rules and don't have to reconfigure those services

-more secure: worse case scenario if our FW goes down is that we loose our monitoring for those services but they don't get exposed to the public interface.

share|improve this question
up vote 1 down vote accepted

you cannot nat it's a super-special reserved network. You'd probably be better off setting the bind address to and then using iptables to filter IPs/Interfaces from which you don't want to allow traffic.

share|improve this answer
I believe I have a very valid use-case and am surprised by your answer. Have you got any references backing up your statement? (I've googled for it and didn't really find anything). If the default ubuntu stack doesn't allow it, do you know where I should be looking at to override that behaviour? – Max Dec 10 '11 at 11:58
Let me explain it like this... A "snat" will mask the source of the packet with whatever you provide. Having a packet appear that it's coming from the same machine it's generated from... makes return packets go to and not the peer it originated from. That's the 1st problem. There are connection tracking plugins for iptables that may help resolve this... but honestly I can think of 0 situations where this would be a good idea. On the flip side... have you considered doing a "ssh tunnel" which would indeed appear to come from – TheCompWiz Dec 12 '11 at 15:24
Your answer and my comment were about the fact that NATing to was not possible. Your second comment is about SNATing which we can leave out, since with or without SNATing on it doesn't work. As for the use case, don't worry we have ours :) Any references sustaining the idea that we can't NAT to would be welcome. – Max Dec 13 '11 at 9:50
As I've previously stated.... and do quite regularly... specifically with nagios... use a ssh tunnel. It's very clean & easy to do... and you can run any queries on the box using an encrypted tunnel. As it's tunneled to the local machine, from mysql's point of view... you ARE coming from the interface. – TheCompWiz Dec 14 '11 at 19:03
Here's a reference: (and I've edited my answer, too) – pepoluan Dec 22 '11 at 16:34

Try deleting this rule:

-t nat -A POSTROUTING -o lo -j SNAT --to-source

I have to totally withdraw my answer; packets from outside a Linux box are not allowed to go to See the following email (and it's preceding ones):

share|improve this answer
makes no difference, actually tested without it in a first place and added it after realized it was not working. – Max Dec 13 '11 at 10:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.