Well, with SuSEfirewall2, this worked out of the box,
No, it did not. You had to configure it.
I read the comments in /etc/sysconfig/SuSEfirewall2, adjusted the documented variables for masquerading, and it worked on first attempt. So without hassle, straightforward.
You only have a single interface in this zone, why do you enable forwarding inside this zone? There is nothing to forward packets between.
No idea, this is activated by default when using firewall-config. But I guess it does not harm?
This will be ignored unless both zones are active. Are they?
Yes, of course, otherwise it would not work. I thought this would be straightforward. I did not complain that masquerading does not work. I have ifcfg-int0: IPADDR='192.168.99.1/24' internal.xml: <zone> <short>Internal</short> <description></description> <interface name="int0"/> </zone> And yes, I did remove all the port configurations ("<service .../>"), as they are not interesting to my present problem.
where 192.168.0.0/16 is in the internal zone/interface.
Did you tell this to the firewalld?
Well, yes, this is my issue.
Do I get you right that with some NAT policy like above,
What is "NAT policy"? What makes you think the policy above has anything to do with NAT?
I do not need "<masquerade/>" on the external zone? Reading the documentation I had the impression that I need both, the NAT rule and the masquerade option on the zone.
Again - what do you call "NAT rule"?
Rule that allows NAT between different zones.
Anyway - firewalld by design controls traffic between zones or (historically) from a zone to the host. <masquerade/> was always highly confusing because it affected traffic from the host to the zone, which is the exact opposite. Using policies makes traffic direction explicit and less confusing.
You cannot have different interface based zones with only a single interface. That should be obvious. You /may/ be able to define a source based zone for your internal traffic. Like
<zone> <short>Internal</short> <description></description> <source address="192.168.0.0/16"/> </zone>
and then to enable masquerading between them
<policy target="ACCEPT"> <ingress-zone name="internal"/>< <egress-zone name="external"/> <masquerade/> </policy>
This will avoid attempts to masquerade HOST -> external packets.
OK, source address on the ingress zone, and masquerade in the policy. It even seems, that the source indication is not needed, if the interfaces in internal.xml are correctly set. It seems that only the move of the masquerade indication is needed. At first glance is seems to work. Thanks!