Symptoms vary and may include:
iptablesrules are not working
You see the following error when trying to create an
iptablesrule in the NAT table or when trying to use the STATE module:
# iptables -t nat -L iptables v1.3.5: can't initialize iptables table 'nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. #
This problem usually occurs because connection tracking (the "conntracks" module) is disabled on your Parallels Virtuozzo Containers (PVC) hardware node (HW Node) by default. This means
iptables is not statefull in the default installation.
You can verify this by checking whether you get the same output as below:
~# grep conntrac /etc/modprobe.d/*parallels.conf /etc/modprobe.d/vz-parallels.conf:options nf_conntrack ip_conntrack_disable_ve0=1
When support for connection tracking is disabled, the NAT table is absent in the list of available tables:
~# cat /proc/net/ip_tables_names mangle filter
Therefore, it is impossible to use the
xt_state modules on the HW Node.
STATE module functionality of
iptables may be replaced by adding explicit complimentary rules for
If you are not satisfied by that workaround or if you need the NAT table functionality, continue reading further.
Before you enable connection tracking support, we strongly recommend considering the following notes and warnings:
Warning 1: Enabling connection tracking uses a lot of resources.
Warning 2: With "conntracks" enabled, the HW Node may become completely unreachable from the network when you have a high network load. If a hosted container has malicious software running, a kernel panic can occur.
That is because the number of connection tracking slots is limited for a physical server. Enabling "conntracks" is especially dangerous for a PVC HW Node, because it allocates two tracking slots for each connection to a container – one for external connection and another one for connecting the HW Node with the container. So if a container opens too many connections, the HW Node will not be able to create any new connections.
This sort of situation might arise due to a DDoS attack of any container. The HW Node administrator would not be able to stop it by stopping a CT or adding
iptables rules, because the administrator could not log in to the Node.
How to enable "conntracks":
Check that all necessary modules are loaded on the Hardware Node:
~# lsmod | grep -E "state|nat" nf_nat_ftp 3489 0 nf_conntrack_ftp 12927 1 nf_nat_ftp iptable_nat 6236 0 nf_nat 23178 3 vzrst,nf_nat_ftp,iptable_nat nf_conntrack_ipv4 9848 3 iptable_nat,nf_nat ip_tables 18021 3 iptable_nat,iptable_mangle,iptable_filter xt_state 1474 2 nf_conntrack 80758 8 vzrst,nf_nat_ftp,nf_conntrack_ftp,iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
Add those modules to the
iptablesconfiguration on the Node:
~# egrep '^IPTABLES_MODULES' /etc/sysconfig/iptables-config IPTABLES_MODULES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length xt_length xt_hl xt_tcpmss xt_TCPMSS xt_multiport xt_limit xt_dscp nf_conntrack iptable_nat" IPTABLES_MODULES_UNLOAD="yes"
/etc/modprobe.d/parallels.confin Virtuozzo 6) and set
~# grep conntrac /etc/modprobe.d/vz-parallels.conf options nf_conntrack ip_conntrack_disable_ve0=0
iptables, logging to verify that it works:
~# egrep '^kern' /etc/rsyslog.conf kern.* /var/log/messages
~]# service iptables restart iptables: Applying firewall rules: [ OK ] iptables: Loading additional modules: ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length xt_length xt_hl xt_tcpmss xt_TCPMSS xt_multiport xt_limit xt_dscp ip_conntrack iptable_nat [ OK ]
(Please note that unloading of kernel modules can fail if modules are in use by running containers.)
~# service rsyslog restart Shutting down system logger: [ OK ] Starting system logger: [ OK ]
Add a test rule, e.g., one to track new SSH connections:
~# iptables -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name ssh_attempt --rsource -j LOG --log-prefix "SSH connection attempt: "
Avoid tracking any other TCP connections to save system resources:
~# iptables -t raw -I PREROUTING -p tcp ! --dport 22 -j NOTRACK
Note: setting rules in the
rawtable might cause issues with CT #1 restart. Update PVA Agent to the latest version.
Try to log in to the server via SSH while monitoring the log:
Jan 11 02:29:19 pvclin47 kernel: [ 106.459592] SSH connection attempt: IN=eth0 OUT= MAC=00:1c:42:ac:d1:c9:00:1e:67:07:55:95:08:00 SRC=192.168.55.3 DST=10.39.3.111 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=44446 DF PROTO=TCP SPT=51889 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 Jan 11 02:29:19 pvclin47 kernel: [ 106.459592] SSH connection attempt: IN=eth0 OUT= MAC=00:1c:42:ac:d1:c9:00:1e:67:07:55:95:08:00 SRC=192.168.55.3 DST=10.39.3.111 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=44446 DF PROTO=TCP SPT=51889 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
Q: What exactly does this option do?
A: This option controls the tracking of packets in the Node's environment. When it is disabled, packets are accepted, routed, etc., but the kernel does not store any information about the packet's connections, as it considers each packet to be a complete unit.
This option also has implications for NAT. For NAT, you need to have the following information: you need to determine the first packet of a connection and decide which of the next packets belongs to this first packet, i.e., which packet should be considered as a "connection."
For information on how to configure "conntracks" on pre-4.7 nodes, refer to this article:
9630 Issues with firewall on HW Node - Impossible to use
Firewall configuration is containers is described in the following article:
126787 Configuring IPTABLES on the node and inside containers