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 have a problem on a Debian Etch machine... For dark and stormy reasons its ip on eth0 is weird but we have to keep it like this...

Its ifconfig:

eth0      Link encap:Ethernet            
          inet addr:    Mask: 

eth1      Link encap:Ethernet  
          inet addr:  Mask:

With the command:

iptables –t nat –L POSTROUTING

I get:

target                prot      opt       source              destination
ACCEPT                0         --           anywhere
MASQUERADE            0         --        !    anywhere

The second rule, if I've understood correctly, does a nat of all the traffic different from In other words all the packets headed to a lan for whom I have a routing rule are sent from the Debian Etch's machine ip, losing their real sender.

I would like this machine not to NAT the traffic not passing through it. I'll try to be clearer... It should NAT only traffic coming from (its ip) and going out from

I am learning linux lately and this is a little too much :/ Can anybody help (maybe giving directions to backup the config so I can be safe in case of total mess)?

Thanks a lot!

share|improve this question
An important information I forgot to add: this is a proxy server using dansguardian and squid... – Pitto Nov 17 '10 at 12:26
up vote 2 down vote accepted

You can back up the current iptables configuration with:

iptables-save >iptables-20101117

That will save the currently running rules which can be restored with:

iptables-restore <iptables-20101117

The "iptables -L" command doesn't list all the information about the rules, including things like Interface restrictions, so we may not be seeing the full picture here. I usually look at the output of "iptables-save" to make sure I'm seeing the full rule information.

As far as the rule goes, there should be no traffic coming from it's internal 128 IP address and going out the 192 interface. Traffic leaving the 192 interface should bind to the 192 interface IP address. So if you don't want the MASQUERADE rule you can remove it.

I typically change rules by editing the file and using iptables-restore on the full rule-set. iptables-restore is atomic, so the full set of new rules get applied at once.

share|improve this answer
This is really good help! I just fear that the masquerade rule is used by some kind of weird service I have no notice about (until I kill this rule) – Pitto Nov 17 '10 at 9:55
+1 really good tip. Didn't know this one. – Antoine Benkemoun Nov 17 '10 at 14:54
Excuse me if I bother again... – Pitto Nov 22 '10 at 9:56

Also, you can get a slightly more verbose out put with:

iptables –t nat –vnL POSTROUTING

Which will show you the input/output interfaces for the rule. (the -n part tells it not to resolve port numbers/IP addresses, which I find easier to look at, but that's more of a taste thing...)

As for the rules, with NAT, I try to stick with interface-based rules, rather than matching IP addresses, as it's more robust in environments where the external IP might change.

The most common outbound NAT rule there would be:

iptables -t nat -I POSTROUTING -s <LAN netblock> -o eth0 -j MASQUERADE

Which makes all traffic from the LAN, bound for the wider world (if that's what eth0 is) will have eth0's IP. (Edited with correction)

However, if I read your request correctly, it sounds like you don't want any NAT at all. Remember that traffic coming directly from the machine itself will always have a source address of the interface it goes out on. You don't need any NAT rules for that.

A useful diagram here: showing the flow of a packet through the various tables.

share|improve this answer
Note: You can't use "-i" with POSTROUTING. You have to use "-s $IPBLOCK" with the IPBLOCK being on the input interface. – Sean Reifschneider Nov 17 '10 at 11:10
d'oh. That's true. Not sure why I wrote the command like that. I'll edit it... – SmallClanger Nov 17 '10 at 14:21

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.