I've got a rack full of Linux servers that host OpenVZ containers and for some reason when I attempt to connect to a certain remote IP from inside a few of the OpenVZ containers (using telnet, for example), I end up connecting to another server on the local network instead. So far, I have looked at the following possibilities:

  1. Checked the server that I'm trying to make the outbound connection from to make sure there are no iptables rules that would redirect the remote IP to a local ip.

  2. Checked our router/firewall to make sure there are no rules that would redirect this outbound connection to a local ip.

  3. Checked the OpenVZ container that it is erroneously connecting to and made sure that it does not have the remote IP configured as an IP alias.

All OpenVZ containers are running CentOS 5.x.

I'm sure it's something simple, but I'm running out of ideas.


When this happens, you should do a traceroute to the remote host. You'll see where in your routing infrastructure the traffic takes a "wrong turn" and you can inspect that device closer. Obviously there's a config or NAT rule or something else somewhere that you've overlooked that's causing this.

  • I had run a traceroute, but on the affected containers it just showed that the trace failed after the first hop. The good news is that I did find the problem. Since I had previously searched for the remote ip using "iptables --list -n" and it wasn't there, I thought it couldn't be iptables. However, after inspecting our iptables script, I did find the NAT rule that was to blame in the OUTPUT chain. That was a bit surprising since the output of "iptables --list -n" does not show the rule. Perhaps iptables doesn't show the OUTPUT chain properly in OpenVZ. Oh well. – Curtis Jan 9 '14 at 18:39

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.