Docker 28.0.2 is expected to be released next week.
Adding
[Service]
Environment="DOCKER_INSECURE_NO_IPTABLES_RAW=1"
to docker.service unit file will make it work even with kernels that do not have CONFIG_IP_NF_RAW.
master ← robmry:skip_raw_rules
opened 04:01PM - 10 Mar 25 UTC
**- What I did**
- fix https://github.com/moby/moby/issues/49557
For kerne… ls that don't have `CONFIG_IP_NF_RAW`, if the env var `DOCKER_INSECURE_NO_IPTABLES_RAW` is set to `"1"`, don't try to create raw rules.
**_Warning:_** When the environment variable is set, direct routing to published ports is possible from other hosts on the local network, even if the port is published to a loopback address. It un-does some of the security hardening described at https://www.docker.com/blog/docker-engine-28-hardening-container-networking-by-default/
**- How I did it**
The env var is `DOCKER_INSECURE_NO_IPTABLES_RAW` ... because that's why the workaround is needed. Alternatively, it could be called something like `DOCKER_INSECURE_ALLOW_DIRECT_ROUTING` ... because that's currently the effect. Then it'd need to do the same thing for an nftables/firewalld implementation.
If we want to add a more "feature-y" way to allow direct routing at some point - it should be via a new "gateway mode" with well defined semantics, something less drastic than `nat-unprotected` (allowing access from remote hosts, but only to published ports, and maybe not to ports published to `127.0.0.1`). That'd work per network rather than globally, and it'd need some different regression testing and more documentation.
So, I went for this simple workaround for kernels without the required module.
**- How to verify it**
New integration test.
Also, checked a container with host port mapping started on a host without `CONFIG_IP_NF_RAW` ...
```
# cat /etc/systemd/system/docker.service.d/insecure_direct_routing.conf
[Service]
Environment="DOCKER_INSECURE_NO_IPTABLES_RAW=1"
# systemctl daemon-reload
# systemctl restart docker
# docker run --rm -ti -p 127.0.0.1:8080:80 alpine
```
In docker's log ...
```
Mar 10 15:38:50 debian2 dockerd[7232]: time="2025-03-10T15:38:50.830162607Z" level=debug msg="DOCKER_INSECURE_NO_IPTABLES_RAW=1 - skipping raw rules" eid=3c070182713114fcf3b58f606cd0d2dc773516360c0bd9eed60bb4899d90d467 ep=elated_keldysh net=bridge nid=b30950846c3a84d5e17e8cf0406ff435a76323e87d41d3fdf47262032e670af6
Mar 10 15:38:50 debian2 dockerd[7232]: time="2025-03-10T15:38:50.830260399Z" level=debug msg="DOCKER_INSECURE_NO_IPTABLES_RAW=1 - skipping raw rules" eid=3c070182713114fcf3b58f606cd0d2dc773516360c0bd9eed60bb4899d90d467 ep=elated_keldysh net=bridge nid=b30950846c3a84d5e17e8cf0406ff435a76323e87d41d3fdf47262032e670af6
```
(And, no rules created in the iptables/ip6tables `raw` table.)
**- Human readable description for the release notes**
```markdown changelog
Add environment variable `DOCKER_INSECURE_NO_IPTABLES_RAW=1` to allow Docker to run on systems where the Linux kernel can't provide `CONFIG_IP_NF_RAW` support. When enabled, Docker will not create rules in the iptables `raw` table. Warning: This is not recommended for production environments as it reduces security by allowing other hosts on the local network to route to ports published to host addresses, even when they are published to `127.0.0.1.` This option bypasses some of the security hardening introduced in Docker Engine 28.0.0.
```
There is one thing to note :
Warning: This is not recommended for production environments as it reduces security by allowing other hosts on the local network to route to ports published to host addresses, even when they are published to 127.0.0.1. This option bypasses some of the security hardening introduced in Docker Engine 28.0.0.
2 Likes