Introduction: A Hidden Network Issue

Developers and system administrators using servers on the OpenStack platform (for example, the C*-M*-D* hosting plans from reg.ru) sometimes encounter mysterious network problems. The internet seems to work, but when trying to transfer large amounts of data or establish connections to certain services, requests may hang or fail due to timeouts.

The provider explains this issue as a feature of their infrastructure:

Servers on the OpenStack platform use VxLAN technology, which reserves 50 bytes for service information. Because of this, the maximum transmission unit (MTU) on the server’s main network interface (ens3) is 1450 bytes.

At the same time, Docker by default configures container network interfaces with an MTU of 1500 bytes. This causes packets sent from a container to exceed the allowable size and prevents them from being transmitted to the global network.

Official Solutions and Their Limitations

The provider suggests manually changing the MTU for Docker containers:

• In docker-compose.yml, add the parameter com.docker.network.driver.mtu: 1450 for each network.
• For docker run and docker build, edit or create the file /etc/docker/daemon.json, specifying "mtu": 1450.

While these methods solve the issue, they have significant downsides:

1. Not global: They require manual configuration changes for each project (docker-compose) or every new Docker installation.
2. Do not fix existing containers: All containers must be restarted and recreated, which can be inconvenient.
3. Easy to forget: A developer moving a project to such a server may not immediately remember to adjust the MTU, leading to wasted debugging time.

A Global and Elegant Solution via iptables

Instead of manually changing every container’s settings, this problem can be solved once and for all at the server level using iptables.

The idea is simple: rather than modifying Docker’s MTU, we can leverage iptables to automatically adjust a special value in TCP packets — MSS (Maximum Segment Size). MSS is the maximum payload size in a TCP packet and is 40 bytes less than the MTU (20 bytes for the IP header and 20 bytes for the TCP header).

An iptables rule will force outbound TCP packets to “announce” a correct MSS based on the outgoing interface’s MTU. This way, the remote host will send smaller packets, avoiding MTU-related issues at the TCP connection level.

Applying the iptables Rule

To apply this rule, we only need to add one line to iptables.

1. Identify your main network interface name. Typically, it is ens3 or eth0. You can check it with ip a. Then set the interface name in the IFACE_NAME variable.

   export IFACE_NAME=ens3
   

2. Run the following command:

sudo iptables -t mangle -A POSTROUTING \
    -p tcp --tcp-flags SYN,RST SYN -o $IFACE_NAME \
    -j TCPMSS --clamp-mss-to-pmtu

What does this command do?

• sudo iptables: Runs the iptables command with administrator privileges.
• -t mangle: Indicates we are working with the mangle table, used for packet modification.
• -A POSTROUTING: Adds a rule to the POSTROUTING chain, which processes packets that have just left the local network and are about to be sent globally.
• -p tcp --tcp-flags SYN,RST SYN: Filters only the first packet in a TCP connection (SYN), which announces the maximum segment size.
• -o $IFACE_NAME: Applies the rule only to packets leaving via the main network interface (in our case, ens3).
• -j TCPMSS --clamp-mss-to-pmtu: The target is TCPMSS, which automatically calculates the maximum MSS based on the outgoing interface’s MTU and sets it. This is more universal than setting a fixed value.

3. Make the rule persistent

By default, iptables rules are temporary and disappear after a server reboot. To save the rule, use system utilities. On most modern Linux distributions (Ubuntu, Debian), you can use netfilter-persistent.

For Ubuntu/Debian:

sudo apt-get install netfilter-persistent
sudo netfilter-persistent save
sudo systemctl enable netfilter-persistent

Conclusion

The iptables solution is preferable to manual Docker configuration changes because it:

• Fixes the issue globally: All containers will work correctly, regardless of how they were created.
• Saves time: No need to remember to change docker-compose.yml or daemon.json for every new project.
• Avoids downtime: No need to recreate already running containers.
• Is universal: The --clamp-mss-to-pmtu flag makes the solution independent of any specific MTU value.

This elegant and reliable solution allows you to focus on development instead of infrastructure issues — perfect for developers who value their time.