Information
Symptoms vary and may include:
Cause
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/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
nf_nat and
xt_state modules on the HW Node.
Resolution
Note:
STATE module functionality of
iptables may be replaced by adding explicit complimentary rules for
INPUT and
OUTPUT chains.
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
iptables configuration 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"
- Edit
/etc/modprobe.d/vz-parallels.conf and set ip_conntrack_disable_ve0=0:
~# grep conntrac /etc/modprobe.d/vz-parallels.conf
options nf_conntrack ip_conntrack_disable_ve0=0
- Enable
iptables, logging to verify that it works:
~# egrep '^kern' /etc/rsyslog.conf
kern.* /var/log/messages
- Restart
iptables:
~]# 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.)
- Restart
syslog:
~# 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 raw table 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
FAQ
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."
Additional information