Narrow down the host network rules installed for the ports used by Antrea

[hongliangl]

Describe the problem

The host network rules added in #7803 make antrea-agent install ACCEPT rules for the ports Antrea listens on, so that Antrea keeps working when the default firewall policy of the Node is to drop. These rules are wider than they need to be, in three different ways.

They are also written to ANTREA-INPUT / ANTREA-OUTPUT before the jump to the NodeNetworkPolicy chains, so a NodeNetworkPolicy cannot narrow them down. That ordering is on purpose, it is what keeps a default-deny policy from locking Antrea out of the Node, but it does mean the rules themselves have to be as narrow as we can make them.

1. The reply rules accept any packet with a matching source port

The rules allowing the replies look like this:

-A ANTREA-INPUT -p tcp --sport 10349 -j ACCEPT
-A ANTREA-OUTPUT -p tcp --sport 10350 -j ACCEPT

There is no destination port and no connection state, so any packet whose source port is 10349 is accepted, whatever it is really going to. The same applies to 10350, 10351 and 10256.

These rules exist because we cannot assume the host has a rule accepting established connections: the Antrea chains are also traversed when the default policy of the built-in chain is to drop. But we can add that condition ourselves, scoped to the port:

-A ANTREA-INPUT -p tcp --sport 10349 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Then only the replies of connections Antrea actually opened are accepted, and a packet with a forged source port is not. This works the same way in every traffic mode and is not affected by NAT, so it is the one change that is safe everywhere.

2. The rules do not match the interface

The tunnel, IPsec, WireGuard and cluster membership traffic can only enter and leave through the transport interface, but the rules match the protocol and the port only. initNodeLatencyHostNetworkFilterRules already matches -i antrea-gw0, the other rules could match the transport interface the same way. networkConfig.TransportIface is available, and matching the interface is not affected by NAT either.

3. The rules do not match the source address, and mostly cannot

This was raised in #7803 (comment). The cluster membership rules accept 10351 from any source, while the gossip only ever comes from another Node, so matching the source against the cluster Node IPs would be tighter.

It does not generalise to the other ports though. IPsec moves IKE and ESP to UDP 4500 when a NAT device is detected between the peers, and WireGuard is expected to work through NAT as well. In both cases the source address the receiving Node sees is the address of the NAT device, not the peer's transport address, so a source match against the Node IPs would drop the traffic, and it would fail silently in the firewall. So the tunnel, IPsec and WireGuard rules should keep accepting any source.

That leaves cluster membership, where a source match is defensible because the gossip needs both directions to work and Nodes behind a NAT would not form a cluster anyway. Before it can be done:

• clusterNodeIPSet / clusterNodeIP6Set are only created and maintained when multicastEnabled && TrafficEncapMode.SupportsEncap(), so addNodeIP and deleteNodeIP would have to run unconditionally.
• They hold the Node IP, while the cluster membership traffic uses the transport address, which is a different address when transportInterface is set. A separate set may be needed rather than reusing this one.
• They are keyed by the Node's PodCIDR, which assumes every Node has one.
• The ipset has to exist before the rules referencing it are installed, otherwise iptables-restore fails as a whole.

Describe the solution you have in mind

Do them in this order, as the value and the risk are very different:

1. Add the connection state condition to the reply rules. Small, safe in every mode, and it closes the widest hole.
2. Match the transport interface on the tunnel, IPsec, WireGuard and cluster membership rules.
3. Decide whether the source match on the cluster membership rules is worth the changes it needs, and whether it should be opt-in.