At the cil_to_netdev (egress) hook, hostFW does (a) ct_lookup and (b) enforce policies.
For traffic not marked with MARK_MAGIC_HOST and therefore having src_sec_id=UNKNOWN_ID, we introduced a regression in v1.18.4 with #41915.
The incriminated piece of code is:
With masquerade, this always resolves to true as src_sec_id=UNKNOWN_ID, independently by the ipcache lookup. We skip hostFw for such packets, regardless their protocol, even non-UDP/TCP.
With masquerade, this now resolve to false, as the ipcache lookup is able to correctly retrieve HOST_ID for these kind of packets. We fail before reaching policies, in the conntrack lookup for all non-UDP/TCP protocols (DROP_CT_UNKNOWN_PROTO).
Same as v1.18. However, we have in this version the --enable-extended-ip-protocols flags, which would allow non-UDP/TCP through a successful conntrack lookup and egress policies. However, with an UNKNOWN_ID policies wouldn't fire anyway, and regarding the CT entry:
- with flag disabled: we don't need to add entry for an unknown protocol. This would fail with DROP_CT_UNKNOWN_PROTO as of today.
- with flag enabled: we add CT entry to allow reply packets.
What now?
Even with --enable-extended-ip-protocols from v1.19 onwards, we still don't need to try to create CT entry when flag is disabled. This restores the old v1.17 behavior and allows users for a smooth upgrade v1.17->v1.18. When upgrading v1.18->v1.19, users should not be affected too, and once completed the upgrade they can enable the flag for starting enforcing policies for new protocols.
Note: even with the flag set, when reaching egress hook with UNKNOWN_ID we don't enforce policies.
At the
cil_to_netdev(egress) hook, hostFW does (a) ct_lookup and (b) enforce policies.For traffic not marked with MARK_MAGIC_HOST and therefore having
src_sec_id=UNKNOWN_ID, we introduced a regression in v1.18.4 with #41915.The incriminated piece of code is:
v1.17
With masquerade, this always resolves to
trueassrc_sec_id=UNKNOWN_ID, independently by the ipcache lookup. We skip hostFw for such packets, regardless their protocol, even non-UDP/TCP.v1.18
With masquerade, this now resolve to false, as the ipcache lookup is able to correctly retrieve HOST_ID for these kind of packets. We fail before reaching policies, in the conntrack lookup for all non-UDP/TCP protocols (DROP_CT_UNKNOWN_PROTO).
v1.19 onwards
Same as v1.18. However, we have in this version the
--enable-extended-ip-protocolsflags, which would allow non-UDP/TCP through a successful conntrack lookup and egress policies. However, with an UNKNOWN_ID policies wouldn't fire anyway, and regarding the CT entry:What now?
Even with
--enable-extended-ip-protocolsfrom v1.19 onwards, we still don't need to try to create CT entry when flag is disabled. This restores the old v1.17 behavior and allows users for a smooth upgrade v1.17->v1.18. When upgrading v1.18->v1.19, users should not be affected too, and once completed the upgrade they can enable the flag for starting enforcing policies for new protocols.Note: even with the flag set, when reaching egress hook with UNKNOWN_ID we don't enforce policies.