On Sun, Aug 06, 2023 at 11:56:33AM -0400, D. Hugh Redelmeier wrote:
| From: Andrei Borzenkov arvidjaar@gmail.com
| It sounds like the documentation bug. For all I can tell, tcp-mss-clamp can | only be used in rich rules and all firewalld regression tests also use it only | in rich rules.
Thanks for the quick reply.
It's a doc bug. tcp-mss-clamp is only valid inside of a `<rich>` element.
(That still leaves the problem of Firewalld crashing with a python stack dump.)
Check `firewall-cmd --state`. I bet it's in failed state because your configuration is invalid.
The stack dump is from the failed start. A few lines above you can see that firewalld performed a fallback to the safe defaults. That being said, it's an ugly failure in the code and should be throwing an intelligible error. Feel free to file an issue on github to improve this.
The log indicates your configuration is broken.
Aug 06 02:29:40 my-hostname firewalld[17576]: ERROR: Failed to load user configuration. Falling back to full stock configuration.
You could also try `firewall-cmd --check-config`.
Speaking without a lot of knowledge:
I try to avoid Rich Rules since they feel like a kind of failure of the model of Firewalld.
Agree. But for uncommon/advanced things it's compromise. We either muddy the CLI with tons of options.. or put the advanced features in rich rules.
I think clamping is required when forwarding is done: the application cannot just ask the (local) interface what its MTU is. So it seems natural to put this in a Policy Object. I guess not all forwarding is inter-zonal, but all mine is. Not all interfaces in a zone need to have the same MTU, but all mine do.
In the mean time, I will go look at Rich Rules again.
This might not be the whole picture. For example, I don't know:
- why PMTU discovery doesn't solve this problem
It should.
- how clamping can work in the face of end-to-end encryption.
The outer IP/TCP is where the MSS negotiation happens. The inner part of the packet is encrypted, not the outer part.
- why my one router works and my other doesn't. They both run Fedora 38 with Firewalld and limit the upstream MTU to 1492.
I don't know without more information: configs, etc.