[HUB] Configuring IPTABLES on the node and inside containers – Virtuozzo Technical Support

Information

Virtuozzo containers can have IPtables rules defined and applied. However, there are certain configuration options to control what is available.

Configuration option in Virtuozzo 6.0 update 6 or later
Configuration options for previous versions
Connection tracking support
Resource limits related to IPtables
Troubleshooting IPtables issues
Firewall configuration by APF/CSF/LFD/...

IPtables configuration in recent versions of Virtuozzo

Virtuozzo (starting from version 6.0 update 6, see Netfilter Mode and netfilter (iptables) modules) have simplified management for IPtables with automatic modules loading if they are needed in containers, that is why it is not necessary to specify the list of modules to load.

This is per-container configuration (it cannot be defined globally), and has few options:

disabled - IPtables modules are not available in the container
stateless - all modules are allowed, without connection tracking
stateful - all modules can be used except NAT
full - no restrictions.

The configuration can be set using the command:

~# vzctl set CTID --save --netfilter MODE

Connection tracking support

Connection tracking is a feature of IPtables to watch and store status of connections passed to/from/via the server.

Few modules depend on this feature:

iptable_nat/ip_nat (NAT rules)
ipt_state/nf_state (match rules for connection state)

Since the hardware node acts as a router for containers in routed mode, the number of connections can be very big and connection tracking is specifically disabled for the node by default, while it is enabled in containers.

For Virtuozzo 6.0 update 6 or later, there is NETFILTER option which defines few levels of IPtables support in containers. Only stateful and full provide connection tracking support.

Configuration option in Virtuozzo 6.0 update 6 or later (Article #126136)

For previous versions, modules are to be added explicitly using their names.

Configuration options for previous versions (Article #746)

Resource limits related to IPtables

Virtuozzo kernel allows to limit the number of IPtables rules which can be set in a container:

~# vzctl set CTID --save --numiptent 100

This is to allow no more than 100 rules in the container.

Troubleshooting

Module is not enabled

Inability to use IPtables modules can result in the following messages:
- not allowed module in a 32-bit system
```
iptables: Unknown error 4294967295
```
- not allowed module in a 64-bit system
```
iptables: Unknown error 18446744073709551615
```
- missing NAT support
```
~# 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.
```
- no module for chain/target/action
```
iptables: No chain/target/match by that name.
```
In all these cases, allow the proper module according to the instructions:
- Configuration option in Virtuozzo 6.0 update 6 or later
- Configuration options for previous versions
The instructions to find out the needed module can be found in this article.
Too many connections are tracked on the node

Overflow in connection tracking table can occur under high rate of establishing new connections for a container.
Module for connection limitation generates errors

This module requires additional option while loading to avoid such error:
```
ip_tables: connlimit match: invalid size 24 != 32
```
Difference in IPtables modules between nodes during online migration

IPtables rules are not restored with the following error if the target server has less modules enabled.
```
1392199066: 1392216717: vzctl : Cannot undump the file: Invalid argument
1392199066: 1392216717: vzctl : Error: iptables-restore exited with 2
```
Try to find the difference in modules as described in the article.

Configuring firewall using scripts like APF, CSF, LFD

There are different scripts to ease IPtables configuration, and it is possible to use these scripts in containers and on the node. The following restrictions are in place, though:

FORWARD chain on the node controls connectivity with containers in routed mode, that is why it should have ACCEPT policy. Check this article for details.
These scripts configure filtering rules relying on connection tracking support, which is not enabled by default (see Connection tracking above). Without connection tracking, new connections are marked as INVALID and dropped.

Ensure you have FORWARD with ACCEPT policy and use state-less configuration sample if connection tracking is not enabled.