iptables-legacy errors in gVisor (release-20240610.0) with --net-raw

[avizack18]

Description

I am encountering errors when using iptables-legacy with gVisor version release-20240610.0. I have configured gVisor with the --net-raw flag.

The following iptables-legacy commands result in the error message "iptables: Invalid argument. Run 'dmesg' for more information":

• iptables -P FORWARD DROP
• iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

However, running dmesg does not reveal any relevant logs related to iptables errors.

Steps to reproduce

1. Install gVisor version release-20240610.0.
2. Configure gVisor with the --net-raw flag.
3. Run the following commands:
   • iptables -P FORWARD DROP
   • iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
4. Observe the "Invalid argument" error message.
5. Run dmesg and verify there are no relevant iptables error logs.

runsc version

runsc version release-20240610.0
spec: 1.1.0-rc.1

docker version (if using docker)

24.0.5

uname

5.15.0-112

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response

[EtiennePerot]

I believe conntrack (the part of iptables that -m state matches against) is not implemented in gVisor at this time. It would be good to understand the use-case of supporting it. Note that you can run iptables outside of gVisor if you want to firewall it off, and that doing so from outside is safer than doing it from inside the sandbox, because having the rules outside the sandbox prevents the sandboxed workload from further tampering with the rules.

cc @kevinGC

[github-actions[bot]]

A friendly reminder that this issue had no activity for 120 days.

[avizack18]

It's used to tunnel traffic to a tun device

[kevinGC]

This is something that would have to be added. We have some connection tracking support implemented to support NAT, but we don't have the -m state matcher implemented. It's not on the roadmap ATM, but as always would be a useful contribution.

As Etienne noted, if you're using iptables for firewalling -- rather than application behavior e.g. redirection and packet modification -- it's safer to install rules outside the sandbox.