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, 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" I translated this to <zone> <short>External</short> <description></description> <masquerade/> <interface name="ext0"/> <forward/> </zone> <policy target="ACCEPT"> <ingress-zone name="internal"/> <egress-zone name="external"/> </policy> where 192.168.0.0/16 is in the internal zone/interface. Do I get you right that with some NAT policy like above, 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. 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), PCI slots are scarce anyway.
Is this worth doing a bug report at github.com/firewalld ?
It is difficult to guess without knowing firewalld configuration, but so far I do not see any bugs.