Outgoing networking issue

[guilloting]

Hi,

First, sorry for my poor English.

We set up yesterday our second hosted Proxmox server (hosted by OVH).
The first one has been running Proxmox 0.9 for a long time, and is doing well.

But the new one, which runs Proxmox 1.1, doesn't acts as it should.

Containers running on it are not able to exhange data outside the physical host (we are using venet, no bridge).

- Ping between host and containers is OK.

- Ping between host and Internet is OK.

- Ping between containers and Internet doesn't work.

There are no ICMP error code (No Route to Host or Host Destination Unreachable)
In fact, ICMP request is sent, but we never get a reply.

After looking around for someone who was in a similar situation, I tried a tcpdump on our older Proxmox server, to see if ICMP request were sent in a good way :

11:51:01.281852 IP 192.168.1.1 > ns202232.ovh.net: ICMP echo request, id 50433, seq 9, length 64
11:51:01.281877 IP ns202232.ovh.net > 192.168.1.1: ICMP echo reply, id 50433, seq 9, length 64
11:51:02.281888 IP 192.168.1.1 > ns202232.ovh.net: ICMP echo request, id 50433, seq 10, length 64
11:51:02.281917 IP ns202232.ovh.net > 192.168.1.1: ICMP echo reply, id 50433, seq 10, length 64
11:51:03.281835 IP 192.168.1.1 > ns202232.ovh.net: ICMP echo request, id 50433, seq 11, length 64
11:51:03.281857 IP ns202232.ovh.net > 192.168.1.1: ICMP echo reply, id 50433, seq 11, length 64
11:51:04.281847 IP 192.168.1.1 > ns202232.ovh.net: ICMP echo request, id 50433, seq 12, length 64
11:51:04.281870 IP ns202232.ovh.net > 192.168.1.1: ICMP echo reply, id 50433, seq 12, length 64
11:51:05.281837 IP 192.168.1.1 > ns202232.ovh.net: ICMP echo request, id 50433, seq 13, length 64
11:51:05.281860 IP ns202232.ovh.net > 192.168.1.1: ICMP echo reply, id 50433, seq 13, length 64

Surprise ! Container is contacting remote hosts using its private IP address instead of the host public address. For sure, it will never get a reply...

Host - route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 venet0
94.23.198.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         94.23.198.254   0.0.0.0         UG    0      0        0 eth0

Container - route -n :

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.0.2.1       0.0.0.0         255.255.255.255 UH    0      0        0 venet0
0.0.0.0         192.0.2.1       0.0.0.0         UG    0      0        0 venet0

I hope someone will be able to help us solve this problem.

Regards,

 

[amravit]

what type of virtual ethernet inside the vps you used

i faced same issues when i used virtio ethernet solution was
using e1000 and updating the latest drivers from intel web side

intel 1000 mt network card driver

 

[guilloting]

Maybe I forgot to tell that we are only using OpenVZ containers.

Redgards,

 

[dietmar]

Surprise ! Container is contacting remote hosts using its private IP address instead of the host public address. For sure, it will never get a reply...

Yes, you should use a public IP for the container.

 

[sylverb]

Hi ,

Yes you should request more public IPs from OVH and everything will be alright.

By the way, how did you install Proxmox on OVH dedicated servers? Could you please tell me more more about it ? I'm trying to install Proxmox on a dedicated server but don't have physical access to the server.

Thanks in advance,
SB

 

[Nemesiz]

Surprise ! Container is contacting remote hosts using its private IP address instead of the host public address. For sure, it will never get a reply...

At this point conpainer has to ping remote internet device with no problem.

# ifconfig
venet0:0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.10.10.12 P-t-P:10.10.10.12 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST POINTOPOINT RUNNING NOARP MTU:1500 Metric:1

# ping google.com
PING google.com (74.125.45.100) 56(84) bytes of data.
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=1 ttl=240 time=135 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=2 ttl=240 time=137 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=3 ttl=240 time=136 ms
64 bytes from yx-in-f100.google.com (74.125.45.100): icmp_seq=4 ttl=240 time=137 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 135.756/136.823/137.653/0.751 ms

# tcpdump icmp -n
tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
21:39:58.778258 IP 10.10.10.12 > 74.125.45.100: ICMP echo request, id 42266, seq 1, length 64
21:39:58.915159 IP 74.125.45.100 > 10.10.10.12: ICMP echo reply, id 42266, seq 1, length 64
21:39:59.781544 IP 10.10.10.12 > 74.125.45.100: ICMP echo request, id 42266, seq 2, length 64
21:39:59.918722 IP 74.125.45.100 > 10.10.10.12: ICMP echo reply, id 42266, seq 2, length 64
21:40:00.784226 IP 10.10.10.12 > 74.125.45.100: ICMP echo request, id 42266, seq 3, length 64
21:40:00.920958 IP 74.125.45.100 > 10.10.10.12: ICMP echo reply, id 42266, seq 3, length 64
21:40:01.788212 IP 10.10.10.12 > 74.125.45.100: ICMP echo request, id 42266, seq 4, length 64
21:40:01.925615 IP 74.125.45.100 > 10.10.10.12: ICMP echo reply, id 42266, seq 4, length 64

If you want to ping from outside to your container - you myst have external IP.

Probably you have disabled ip_forward. This is why you dont have a connection between remote host and container.

 

[guilloting]

Yes, you should use a public IP for the container.

We have a limited number of free public addresses. There will actualy be about 3à containers on this server...

At this point conpainer has to ping remote internet device with no problem.

If you want to ping from outside to your container - you myst have external IP.

Probably you have disabled ip_forward. This is why you dont have a connection between remote host and container.

The container is sending ICMP request with it's private IP address, and I don't understand why.

With venet, packets should go that way : venet0 -> ethx -> Internet, but it's like they are going that way venet0 -> Internet...

I don't want the container to be pingable from the outside. At this time, I just want it to access Internet to install some packages.

And ip_forward is enabled on the server for eth0.

 

[guilloting]

OVH provides automated installation of Proxmox 1.1 on their dedicated servers.

 

[dietmar]

I don't want the container to be pingable from the outside. At this time, I just want it to access Internet to install some packages. And ip_forward is enabled on the server for eth0.

Then you need some kind of NAT. I guess OVH support can tell you how to do that on there servers.

 

[guilloting]

We are currently using NAT for incoming connections on our other Proxmox server.

But, in my experience of OpenVZ (with or without Proxmox), outgoing traffic of containers has always been "routed" by the host. It is the way it works on our Proxmox 0.9 server, without making any special configuration.

 

[dietmar]

But, in my experience of OpenVZ (with or without Proxmox), outgoing traffic of containers has always been "routed" by the host.

You can route private IPs to the internet, sure. Unfortunately you will not receive any answer ;-)

It is the way it works on our Proxmox 0.9 server, without making any special configuration.

We did not change anything in our network model. And I am 100% sure that simply routeing private IPs to the internet does not work with 0.9.

Maybe someone configured iptables NAT rule for you?

- Dietmar

 

[guilloting]

You can route private IPs to the internet, sure. Unfortunately you will not receive any answer ;-)

We did not change anything in our network model. And I am 100% sure that simply routeing private IPs to the internet does not work with 0.9.

Maybe, there is a missunderstanding.
Here is how our hosted servers are configured :

           host1.asperience.fr--------[I]Internet[/I]--------host2.asperience.fr
                   |                                          |
                   |                                          |
           -----------------                           -----------------
           |                |                         |                 |
             10.0.0.0/16 VE                              10.1.0.0/16 VE

host1 and host2 both have one public IP address.
There are about 20 VE running on host1. They are using venet device with a 10.0.0.0/16 IP address and are able to connect to remote servers (typically by http)
There is currently one VE running on host2. It is using venet device with 10.1.0.0/16 IP address and cannot access any Internet service (http, ssh, ICMP, etc.) There is no error message from any of those protocols. There is only no answer.

There are some NAT rules on host1, which allow us to use Apache, Bind and Postfix servers. Those rules only apply to incoming traffic. There is no other rules.

Forwarding is enabled on host1 and host2.

The only difference I could find is that a tcpdump on both nodes don't give the same results.

tcpdump on host2 when using a host1's VE to ping host2 :

14:09:00.581720 IP host1.asperience.fr > host2.asperience.fr.asperience.fr: ICMP echo request, id 12112, seq 8, length 64
14:09:00.581732 IP host2.asperience.fr.asperience.fr > host1.asperience.fr: ICMP echo reply, id 12112, seq 8, length 64

tcpdump on host1 when using a host2's VE to ping host1 :

14:05:26.506209 IP 10.1.0.1 > host1.asperience.fr: ICMP echo request, id 54530, seq 12, length 64
14:05:26.506230 IP host1.asperience.fr > 10.1.0.1: ICMP echo reply, id 54530, seq 12, length 64

It appears clearly that there is a significant difference, as host2's VE are sending request over INternet with their private IP.

And I'm looking for the source of this difference.

Maybe someone configured iptables NAT rule for you?

- Dietmar

BTW, I have installed, configured and I am responsible of this server.

 

[Nemesiz]

I would like to see iptables-save result if its possible