Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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).

Configuration
-mysql bind-address = 127.0.0.1
-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

Verifications
-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)
-connectivity to eth0 on 3306 is fine because when I set the bind-address to the IP owned by eth0 I can connect.

Issue
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 127.0.0.1 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

Requirements:
-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.

Benefits

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

2 Answers 2

up vote 1 down vote accepted

you cannot nat 127.0.0.1 it's a super-special reserved network. You'd probably be better off setting the bind address to 0.0.0.0 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? –  user64204 Dec 10 '11 at 11:58
2  
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 127.0.0.1... 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 127.0.0.1... –  TheCompWiz Dec 12 '11 at 15:24
    
Your answer and my comment were about the fact that NATing to 127.0.0.1 was not possible. Your second comment is about SNATing which we can leave out, since with or without SNATing on 127.0.0.1 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 127.0.0.1 would be welcome. –  user64204 Dec 13 '11 at 9:50
1  
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 127.0.0.1 interface. –  TheCompWiz Dec 14 '11 at 19:03
    
Here's a reference: lists.netfilter.org/pipermail/netfilter/2004-August/055117.html (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 127.0.0.1

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

http://lists.netfilter.org/pipermail/netfilter/2004-August/055117.html

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

Your Answer

 
discard

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.