I run a small network where a linux web/mail server also provides NAT for a collection of windows boxes. One of these windows machines is apparently misbehaving (ZeroAccess botnet even though I can't find any problems using Norton PowerEraser and have only been able to find 3 outgoing port 16465 packets in /var/syslog in weeks of logging). For some reason setting a firewall rule to drop all outgoing 16465 packets doesn't solve the problem, either, but that's an unrelated issue.

This issue is causing the mail server to be blacklisted with, for example, spamhaus.org. Since I can't find the infected windows host, I hit upon the idea of using IP aliasing to send the NAT traffic out through a different IP address.

External interface:


Internal interface:


In my firewall rules I then changed

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to


iptables -t nat -A POSTROUTING -s -o eth0 -j SNAT --to

The problem is now everything appears to be going out as, including traffic from the mail server. If I ssh from the firewall host to another external machine, the connection is identified as coming from

This doesn't make sense to me as I'm specifically specifying the source IP's which are supposed to be NATed. Originally I tried the line above without "-s" and got exactly the same result.

Any thoughts on what is going on? I'm not an iptables expert by stretch of the imagination, but have made an effort to try and research this before posting to serverfault.


root@www:etc# ip ro dev eth0  proto kernel  scope link  src dev eth0  proto kernel  scope link  src dev eth1  proto kernel  scope link  src
default via dev eth0  src  metric 100
default via dev eth0  metric 100
  • 1
    Show your ip ro output – poige Dec 15 '13 at 21:56
  • See edited question above. – pgoetz Dec 16 '13 at 0:44

The "magic" part is not the SNAT rule or the NAT table altogether, it is this routing table entry:

default via dev eth0  src  metric 100

it is telling your kernel to use for outbound locally-initiated connections (as long as the socket is not explicitly bound to a specific address upon creation) if the destination is reachable via this route - which would be the case for all "external" destinations as this is your default route. You should redefine it as

default via dev eth0  src  metric 100

to get the expected behavior.

| improve this answer | |
  • Thanks for this. My ubuntu server install is setting up this route automatically somehow based on the /etc/network/interfaces file; now I just need to figure out how/why and what to do to fix it. – pgoetz Dec 16 '13 at 3:37
  • @pgoetz The quick & dirty fix obviously would consist of ip route del default via dev eth0 src metric 100 && ip route add default via dev eth0 src metric 100. The startup route definition would probably be in the interfaces file but could indeed be elsewhere - e.g. in the hotplug daemon configuration. – the-wabbit Dec 16 '13 at 8:54
  • I'm frustrated by how poorly I understand how the routing system works. In particular, I just ran the command suggested by poige below ip ro add default via and that fixed the issue, even thought the errant route is still in place. In the interfaces file do I need to make the route commands part of some auto ethN stanza, or can they just stand alone anywhere in the file? – pgoetz Dec 16 '13 at 10:03
  • @pgoetz ip route add by default would add with a metric of 0 - which means the route added would be a higher-priority route than the existing one with a metric of 100. Additionally, if you omit the src specification, the source IP address chosen would be the one of the interface facing the route (which is eth0 in your case) - this is why it works as a fix. I would expect to have the route added via an up option to an interface definition, but it really might be anywhere else, including a hotplug script or a separate startup script running on its own, depending on your configuration. – the-wabbit Dec 16 '13 at 16:52

Ok, so I as thought — your server just uses this IP as outogoing one. Actually you don't need 2 default routes at all and it's even misleading. You have to use only one:

ip ro add default via

Alias you're using doesn't need to have special default route entry, since more than likely it's being routed back by your ISP using the primary link (address) of your interface.

| improve this answer | |
  • Yes, I agree. I had no idea this route was being set up. My Ubuntu server install is doing this automatically; I didn't/wouldn't have configured it this way, of course, but your initial question identified the problem. – pgoetz Dec 16 '13 at 3:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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