Networking issue : making host and guest talking to each other

[darquandier]

Hello.
I'm stuck with a problem configuring network between host and guest on a proxmox installation supporting only containers.

I managed to create a container that has a bridged ethernet, and its own public ip which is good.
But still not enough for my needs.

I need to have a second interface on the guest that can ping and be pinged by the host, since the initial working interface will be busy with a vpn and I'd need some kind of access for SSHing and web administration.

I intend to have that interface routed by the host on a couple of ports, but I can't even set up this kind of secondary network interface.

I tried many guides, especially from http://wiki.openvz.org/Virtual_Ethernet_device but for the heck of it, I can't manage to have the guest ping the host (and vice-versa).

Would anyone have a suggestion since i'm starting form scratch again and knowing i really need that bridged interface ?

 

[darquandier]

Both sides? Would you be more specific about this?

Well, the host should be able to see the guest on the networking (i.e. with a ping), and the guest should be able to see the host the same way (in addition to having the bridged interface that allows the guest to have a public IP of course).

The two should be member of the same LAN.
In my tests I managed to have them have NICs on the same LANs but they weren't able to ping each other.

 

[darquandier]

Well, some advancements.
I can make the container ping the host (CT -> CT0), by using this method :
* create a tap device on CT0 :

tunctl -t tap0

* up it with this :

ifconfig tap0 192.168.23.1

* create a container CT101 with bridged ethernet
* on CT0 :

vzctl set 101 --ipadd 192.168.23.101 --save

* on CT101 :

ip route add 192.168.23.0/24 dev venet0

Now from CT101, ping 192.168.23.1 answers correctly as well as ping google.com, meaning communications are going fine from this point.

Still, from CT0, I cannot ping CT101 with ip 192.168.23.101.

The weird thing is that if I create a CT102 with only a venet with address 192.168.23.2, everything works perfectly with the tap0 device set up.

I'm guessing there is some routing trouble there...

On CT101 :

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.0.2.1       0.0.0.0         255.255.255.255 UH        0 0          0 venet0
[bcastbridgeip] 0.0.0.0         255.255.255.255 UH        0 0          0 eth0
192.168.23.0    0.0.0.0         255.255.255.0   U         0 0          0 venet0
0.0.0.0         [bcastbridgeip] 0.0.0.0         UG        0 0          0 eth0
0.0.0.0         192.0.2.1       0.0.0.0         UG        0 0          0 vnet0

CT101 interfaces file :

# Auto generated lo interface
auto lo
iface lo inet loopback

# Auto generated venet0 interface
auto venet0
iface venet0 inet static
        address 127.0.0.1
        netmask 255.255.255.255
        broadcast 0.0.0.0
        up route add -net 192.0.2.1 netmask 255.255.255.255 dev venet0
        up route add default gw 192.0.2.1
auto venet0:0
iface venet0:0 inet static
        address 192.168.23.101
        netmask 255.255.255.255
        broadcast 0.0.0.0

auto eth0
iface eth0 inet static
        address [publicip]
        netmask 255.255.255.255
        broadcast [publicip]
        post-up route add [bcastbridgeip] dev eth0
        post-up route add default gw [bcastbridgeip]
        post-down route del [bcastbridgeip] dev eth0
        post-down route del default gw [bcastbridgeip]

On CT0 :
# netstat -rn

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.23.101  0.0.0.0         255.255.255.255 UH        0 0          0 venet0
192.168.23.2    0.0.0.0         255.255.255.255 UH        0 0          0 venet0
192.168.23.0    0.0.0.0         255.255.255.0   U         0 0          0 tap0
91.121.177.0    0.0.0.0         255.255.255.0   U         0 0          0 vmbr0
0.0.0.0         91.121.177.254  0.0.0.0         UG        0 0          0 vmbr0

 

[darquandier]

Ok, I found out that the thing stopping two-way communication is this command in the interfaces config file :

route add default gw 91.121.177.254

I'd rather have routing that allows both way communication on the 192.168.23.0 lan and on the internet, based on source and target.