OpenVZ: access physical server vs. accessing virtual servers

Posted on

OpenVZ: access physical server vs. accessing virtual servers – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about linux, ssh, virtualization, openvz, .

I am just playing around with OpenVZ and had no experience with virtualization before. So I have the following problems in understanding this virtual infrastructure:

I have a physical Linux server, which has an IP address (e.g. and I have 2 virtual server instances running in OpenVZ. I want to reach both virtual servers via ssh. So what IP address should I use then?

Do I need 3 IP addresses in total?

  • one for the physical main server
  • one for the 1st virtual server and
  • one for the 2nd virtual server

or how can openVZ decide which instance to take?

Solution :

Each OpenVZ VM will have it’s own IP address assigned, with it’s own SSH daemon running and listening on the IP address for the VM. When you want to SSH into the host, you use the host’s IP address, and when you want to SSH into one of the guests, you use the guest’s IP address. (When I say “IP address”, you could also substitute “DNS entry that refers to the IP address”).

In most ways (at least at this early stage of your learning curve), you can think about a VM as being just like a real, physical machine in all the ways that matter, as far as using it on a day-to-day basis.

I would defiantly suggest looking into a DNAT setup on the hardware node.

Here is my working setup (with a few things obfuscated):


-A INPUT -i vzpb -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT
-A OUTPUT -o vzpb -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT

# Allow ping to and from
-A INPUT   -p icmp --icmp-type 8 -j ACCEPT
-A INPUT   -p icmp --icmp-type 0 -j ACCEPT
-A OUTPUT  -p icmp --icmp-type 0 -j ACCEPT
-A OUTPUT  -p icmp --icmp-type 8 -j ACCEPT

# All new DROP
-A INPUT -m state --state NEW -j REJECT
-A OUTPUT -m state --state NEW -j REJECT

# All non-tcp DROP
-A INPUT ! -p tcp -j REJECT
-A OUTPUT ! -p tcp -j REJECT

# username xsmith = 1234 (XX State University)
#-A INPUT -m owner --uid-owner 1234 -j REJECT



# SNAT (to give Internet access for the local containers)
-A POSTROUTING -p tcp -o vzpb -j SNAT --to-source
# upd is needed for DNS
-A POSTROUTING -p udp -o vzpb -j SNAT --to-source

-A PREROUTING -p tcp -d --dport 22 -j DNAT --to-destination
# SNAT --to-source NOT required

# DNAT Web
-A PREROUTING -p tcp -d --dport 80 -j DNAT --to-destination
-A POSTROUTING -p tcp -d --dport 80 -j SNAT --to-source
# --to-source required

  • Hardware node public:
  • Hardware node local:
  • Container local:
  • You will probably need to remove all the “-o vzpb” and “-i vzpb” because I have veth and you probably have the default venet (please read

Also, put this into you hardware nodes’s /etc/sysctl.conf and run sysctl -p:

### OpenVZ settings (2011-01-25)
# from

# On Hardware Node we generally need packet
# forwarding enabled and proxy arp disabled

net.ipv4.conf.default.proxy_arp = 0

# Enables source route verification
net.ipv4.conf.all.rp_filter = 1

# Enables the magic-sysrq key
kernel.sysrq = 1

# TCP Explict Congestion Notification
net.ipv4.tcp_ecn = 0

# we do not want all our interfaces to send redirects
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0

Option 2

To go even more flexible and secure, consider removing all public IPs from the hardware node and putting the above NAT configuration into a container dedicated to the purpose of NAT only. That container will need a public IP (that can be the only Public IP on that machine).

The NAT container will need MAC-level access to the public network interface so you will need to switch from VENET to VETH:

NOTE: veth can be very secure if you firewall your bridge(s) correctly.

To do veth you would have to read this page a lot:

Leave a Reply

Your email address will not be published.