containers
Ability to disable NAT for IPv6 GUA
Good day,
So I'm in a pretty weird situation right now. I created a bridge network in Podman with a GUA /56 subnet hoping to give each container a publicly available address. However, I have no way of instructing Podman to disable NAT for this specific bridge network. My current stop gap workaround is to just prepend a RETURN rule for all the subnet in the NAT chain as so ip6tables -t nat -I POSTROUTING -s XXXX:YYYY:ZZZZ:000::/56 -j RETURN
I want to do this in a clean way without having to wrangle iptables. How feasible is this?
I don't think this is possible right now, but should not be difficult to add - just need to detect if the address is global scoped and decline to add NAT rules if so.
The ip6tables rule is working wonderfully right now so it's not a priority but it'd be appreciated if it could get integrated into netavark and eventually podman
Will port forwarding still work without the NAT? I understand that it is not really needed with global addresses but if not we might cause regressions to user who need it.
I think it ought to - though we might need to create some of the normal NAT chains to make sure they exist (just not the ones that actually match and translate).
It's also possible to make NAT opt-out like how Docker does it with com.docker.network.bridge.enable_ip_masquerade. This way you'll have to explicitly enable an option to disable NAT for a specific network. Should theoretically prevent regressions instead of doing it automatically by detecting ULA/GUA
Having an option to disable masquerading, like Docker has, would be nice anyway. I'm currently investigating whether I could use a different output interface with Podman, but this doesn't seem possible (except when using slirp4netns). While in Docker this is possible by disabling masquerading and manually applying an SNAT rule (as for example described here ). I guess this would also work in Podman when overruling the masquarade using an earlier (/higher priority) SNAT rule. But obviously is a hack as well same as written in this tickets start post.
