I'm trying to NAT traffic sent to the server's private interface to the loopback (because MySQL
bind-address is on
127.0.0.1 and can't be changed but I still need to reach it via the private interface).
-enabled ip forwarding with
sysctl -w net.ipv4.ip_forward=1
-setup iptables as follows (
eth0 is the private interface)
-P FORWARD ACCEPT -P OUTPUT ACCEPT -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 127.0.0.1 -t nat -A POSTROUTING -o lo -j SNAT --to-source 127.0.0.1
-the mysql bind is OK (
telnet 127.0.0.1 3306 works fine)
-ip forwarding is properly enabled (
sysctl net.ipv4.ip_forward gives 1)
3306 is fine because when I set the
bind-address to the IP owned by
eth0 I can connect.
bind-address on localhost and the above iptables rules I can't connect to the IP owned by
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
127.0.0.1 as both source and destination.
Q: What am I missing to NAT
lo on port
additional info: running
ubuntu server 10.04 with
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.