On Thu, Sep 12, 2024 at 3:17 PM Manfred Schwarb <manfred99@gmx.ch> wrote:
Am 12.09.24 um 13:24 schrieb Andrei Borzenkov:
On Thu, Sep 12, 2024 at 2:07 PM Manfred Schwarb <manfred99@gmx.ch> wrote:
I just did some experiments with firewalld, as I really did not change anything on the network side. And indeed: I removed "<masquerade/>" in external.xml, and now I get curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.112
So it has to do with the masquerading! I do also have some policies/NAT_int_to_ext.xml, but removing this policy did not change anything. The only thing that made things working was the removal of "<masquerade/>".
Now 1) why does masquerading influence alias IP's?
Masquerading maps all outgoing packets to the interface primary address. Only one address can be primary and that is what masquerading uses.
2) how can I fix this?
Do not use masquerading for packets originating in your host. If you need masquerading for internal networks, define firewalld policies to manage traffic between internal and external networks and enable masquerading in these policies. Do not enable masquerading in the firewalld zone itself.
Well, with SuSEfirewall2, this worked out of the box,
No, it did not. You had to configure it.
I had FW_DEV_EXT="ext0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_DEV="zone:ext" FW_MASQ_NETS="192.168.0.0/16"
So, you told SuSEfirewall2 to only masquerade packets from the network(s) 192.168.0.0/16. Which is more or less what I already said.
I translated this to <zone> <short>External</short> <description></description> <masquerade/> <interface name="ext0"/> <forward/>
You only have a single interface in this zone, why do you enable forwarding inside this zone? There is nothing to forward packets between.
</zone>
Where do you see any reference to the networks 192.168.0.0/16 here?
<policy target="ACCEPT"> <ingress-zone name="internal"/> <egress-zone name="external"/> </policy>
This will be ignored unless both zones are active. Are they?
where 192.168.0.0/16 is in the internal zone/interface.
Did you tell this to the firewalld?
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"?
The interface "ext0" is used to communicate to the world, both for the attached internal network and for the box itself. It does not make sense to have two separate NIC's ext0 (for the masquerading) and ext1 (for the box),
It makes all sorts of sense. It is more manageable and more secure.
PCI slots are scarce anyway.
Then do not claim that "it makes no sense". 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.