Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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

In setting up our OpenStack environment, I ran into a problem that was preventing instances from contacting a server running on the host. The metadata service (which exposes an HTTP API) runs on port 8775 on the host, and the OpenStack networking code adds the following DNAT rule to grant access via a special address on port 80:

  -p tcp -m tcp --dport 80 -j DNAT --to-destination 

Instances are connected to the host via a local bridge device, and is assigned to lo.

While this rule successfully matches packets originating from a guest instance trying to access, they never reach the listening service.

Replacing this DNAT rule with a largely equivalent REDIRECT makes everything work correctly:

  -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8775 

I'm trying to understand why the REDIRECT works and the DNAT fails. It's not clear from the iptables documentation whether or not the DNAT rule is expected to work for locally destined traffic. I'm hoping someone here can provide an authoritative answer, ideally backed up by documentation, or can suggest what might be amiss in my configuration that is preventing the DNAT rule from working as expected.

share|improve this question
up vote 3 down vote accepted

What you're trying to do is explicitly denied by the kernel.

You can't send packets from non 127/8 addresses to 127/8. The kernel filters them out and drops them as it considers them "martians".

This presumably happens because rp_filter defaults to on. Possibly disabling it might alter this behavior (although that will disable some potentially crucial security protection).

With the REDIRECT you're not changing the IP, which is why it works. To put it another way, if you're going to use DNAT you can send it to anything outside of

share|improve this answer
I ran across that mailing list message, too. I was hoping for something more recent, but I guess that will do. Thanks! – larsks Jun 21 '12 at 3:07
As I said, this is more likely due to rp_filter rather than some magic denial (although I haven't tested, nor looked at the source code). Either way, you're better off to not DNAT to 127/8. – bahamat Jun 21 '12 at 18:04

According to the netfilter NAT HOWTO:

There is a specialized case of Destination NAT called redirection: it is a simple convenience which is exactly equivalent to doing DNAT to the address of the incoming interface.

It's slightly more intelligent in that it chooses the DNAT target address as the address of the device which the packet was received on. In your case it would DNAT the packets to the address on the bridge device, and not to

share|improve this answer

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.