Sounds like this kind of setup would autogenerate subtle firewall misconfigurations that result in mysterious failure modes. Like blocking ICMP which breaks TCP path MTU discovery. Or blocking outbound 53/tcp.

Blocking outbound 53/* is often great. Many services don't need DNS (which is usually UDP not TCP) and it is known to be a very frequent covert channel for infiltrators. AFAIK tcp/53 is most frequently used for zone transfers... not something you'd want to encourage on most production servers!

Restricted ICMP (certain message types only) could be a default permit. If you have an internal service running over known virtual infrastructure to an external-facing proxy, MTU path discovery may be unnecessary anyway.

It doesn't have to be nazi, just better than nothing.

Those were just some examples - I was trying to point out that this method will generally give you subtly broken firewall rules.

(re DNS: the DNS protocol uses both TCP and UDP interchangeably, it switches to TCP when the message size crosses a threshold. Many kinds of DNS messages can be over the limit. See eg https://github.com/moby/moby/issues/24344)

You don't need to rigidly and purely enforce rules only from test results but rather also embedded wisdom, defaults and recommendations.

ICMP is a well known gotcha and the only such protocol in its class.

I've personally never seen a fallback to TCP requirement in the wild but you could easily say "if DNS then enable both protocols" as a general rule, and add <received wisdom>.

These are easy to add as policies and will result in better rules than manually configured systems in many cases, if documented. Everyone's happy.

Your comment reminded me of this talk https://youtu.be/BuFTHOgsgAY especially the conclusion that something that rely on access patterns can't be trusted because it's almost impossible to validate all code paths.

Perfection is not required.