Outgoing IP of alias interface
Hi, I recently upgraded from Leap 15.5 to 15.6 and at the same time from SuSEfirewall2 to firewalld. Now I find alias interfaces are not working correctly anymore. I want to have two IP's on one NIC, which are separately addressable: ifcfg-ext0: IPADDR='111.111.111.111/24' IPADDR_0='111.111.111.112/24' LABEL_0='0' so I can do curl --interface ext0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.112 This used to work fine, but now I get curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 I.e. the main IP is used for all outgoing traffic, and not the requested one. Has anybody a clue what might go wrong? Does this need some special treatment in firewalld? Cheers, Manfred
On Thu, Sep 12, 2024 at 11:13 AM Manfred Schwarb <manfred99@gmx.ch> wrote:
Hi,
I recently upgraded from Leap 15.5 to 15.6 and at the same time from SuSEfirewall2 to firewalld. Now I find alias interfaces are not working correctly anymore.
I want to have two IP's on one NIC, which are separately addressable: ifcfg-ext0: IPADDR='111.111.111.111/24' IPADDR_0='111.111.111.112/24' LABEL_0='0'
so I can do curl --interface ext0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.112
This used to work fine, but now I get curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 I.e. the main IP is used for all outgoing traffic, and not the requested one.
Has anybody a clue what might go wrong?
Show output of ip a
Does this need some special treatment in firewalld?
No. It is unrelated to the firewall.
Am 12.09.24 um 11:29 schrieb Andrei Borzenkov:
On Thu, Sep 12, 2024 at 11:13 AM Manfred Schwarb <manfred99@gmx.ch> wrote:
Hi,
I recently upgraded from Leap 15.5 to 15.6 and at the same time from SuSEfirewall2 to firewalld. Now I find alias interfaces are not working correctly anymore.
I want to have two IP's on one NIC, which are separately addressable: ifcfg-ext0: IPADDR='111.111.111.111/24' IPADDR_0='111.111.111.112/24' LABEL_0='0'
so I can do curl --interface ext0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.112
This used to work fine, but now I get curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 I.e. the main IP is used for all outgoing traffic, and not the requested one.
Has anybody a clue what might go wrong?
Show output of
ip a
I did not change any configuration during upgrade. Here is the requested output: 4: ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether ... brd ff:ff:ff:ff:ff:ff altname enp10s0 inet 111.111.111.111/24 brd 111.111.111.255 scope global ext0 valid_lft forever preferred_lft forever inet 111.111.111.112/24 brd 111.111.111.255 scope global secondary ext0:0 valid_lft forever preferred_lft forever
Does this need some special treatment in firewalld?
No. It is unrelated to the firewall.
On Thu, Sep 12, 2024 at 12:52 PM Manfred Schwarb <manfred99@gmx.ch> wrote:
Am 12.09.24 um 11:29 schrieb Andrei Borzenkov:
On Thu, Sep 12, 2024 at 11:13 AM Manfred Schwarb <manfred99@gmx.ch> wrote:
Hi,
I recently upgraded from Leap 15.5 to 15.6 and at the same time from SuSEfirewall2 to firewalld. Now I find alias interfaces are not working correctly anymore.
I want to have two IP's on one NIC, which are separately addressable: ifcfg-ext0: IPADDR='111.111.111.111/24' IPADDR_0='111.111.111.112/24' LABEL_0='0'
so I can do curl --interface ext0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.112
This used to work fine, but now I get curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 I.e. the main IP is used for all outgoing traffic, and not the requested one.
Has anybody a clue what might go wrong?
Show output of
ip a
I did not change any configuration during upgrade. Here is the requested output:
4: ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether ... brd ff:ff:ff:ff:ff:ff altname enp10s0 inet 111.111.111.111/24 brd 111.111.111.255 scope global ext0 valid_lft forever preferred_lft forever inet 111.111.111.112/24 brd 111.111.111.255 scope global secondary ext0:0
This looks OK and I cannot reproduce it. On both Leap 15.6 and Tumbleweed curl correctly binds to the second address matching address label ("alias name"). Can you run strace curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi and upload output to https://paste.opensuse.org/
Am 12.09.24 um 11:29 schrieb Andrei Borzenkov:
On Thu, Sep 12, 2024 at 11:13 AM Manfred Schwarb <manfred99@gmx.ch> wrote:
Hi,
I recently upgraded from Leap 15.5 to 15.6 and at the same time from SuSEfirewall2 to firewalld. Now I find alias interfaces are not working correctly anymore.
I want to have two IP's on one NIC, which are separately addressable: ifcfg-ext0: IPADDR='111.111.111.111/24' IPADDR_0='111.111.111.112/24' LABEL_0='0'
so I can do curl --interface ext0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.112
This used to work fine, but now I get curl --interface ext0:0 http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 I.e. the main IP is used for all outgoing traffic, and not the requested one.
Has anybody a clue what might go wrong?
Show output of
ip a
Does this need some special treatment in firewalld?
No. It is unrelated to the firewall.
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? 2) how can I fix this? Is this worth doing a bug report at github.com/firewalld ?
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.
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.
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.
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.
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!
On 2024-09-12 19:00, Manfred Schwarb wrote:
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.
There is a script that converts a SuSEfirewall2 configuration to a firewalld configuration. Did you use it? Although it may produce a huge configuration. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
Am 13.09.24 um 13:36 schrieb Carlos E. R.:
On 2024-09-12 19:00, Manfred Schwarb wrote:
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.
There is a script that converts a SuSEfirewall2 configuration to a firewalld configuration. Did you use it?
Yes I tried, but it was not able to convert my relatively simple setup. It refused to produce a configuration.
Although it may produce a huge configuration.
On 2024-09-13 13:41, Manfred Schwarb wrote:
Am 13.09.24 um 13:36 schrieb Carlos E. R.:
On 2024-09-12 19:00, Manfred Schwarb wrote:
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.
There is a script that converts a SuSEfirewall2 configuration to a firewalld configuration. Did you use it?
Yes I tried, but it was not able to convert my relatively simple setup. It refused to produce a configuration.
Argh :-( You could try with a simple configuration, as simple as possible. Just the masquerading part. But if you have a working config now, there is not much point, just academic. You might report the failure in Bugzilla. -- Cheers / Saludos, Carlos E. R. (from 15.5 x86_64 at Telcontar)
On 12.09.24 10:13, Manfred Schwarb wrote:
This used to work fine, but now I get curl --interface ext0:0http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 I.e. the main IP is used for all outgoing traffic, and not the requested one.
Has anybody a clue what might go wrong?
Check whether masquerading is active for the corresponding zone, e.g. external: firewall-cmd --zone=external --query-masquerade If so, disable it (for both running and permanent configuration): firewall-cmd --zone=external --remove-masquerade firewall-cmd --permanent --zone=external --remove-masquerade HTH -- Till -- Dipl.-Inform. Till Dörges doerges@pre-sense.de www.pre-sense.de/fcknzs PRESENSE Technologies GmbH Nagelsweg 41, D-20097 HH Geschäftsführer/Managing Director AG Hamburg, HRB 107844 Till Dörges USt-IdNr.: DE263765024 Dieses Jahr sind wir wieder auf der *it-sa* in Nürnberg: 22.-24. Oktober 2024, Halle 7, Stand 503 https://www.itsa365.de/de-de/companies/p/presense-technologies-gmbh Wir freuen uns auf Ihren Besuch!
Hi Till, Am 12.09.24 um 13:23 schrieb Till Dörges:
On 12.09.24 10:13, Manfred Schwarb wrote:
This used to work fine, but now I get curl --interface ext0:0http://example.com/show-HTTP_CLIENT_IP.cgi 111.111.111.111 I.e. the main IP is used for all outgoing traffic, and not the requested one.
Has anybody a clue what might go wrong?
Check whether masquerading is active for the corresponding zone, e.g. external:
firewall-cmd --zone=external --query-masquerade
If so, disable it (for both running and permanent configuration):
firewall-cmd --zone=external --remove-masquerade firewall-cmd --permanent --zone=external --remove-masquerade
Thanks for your hint, the masquerading was indeed the culprit. Unfortunately I need the masquerading, but with the help of Andrei I could solve the problem by moving the <masquerade/> tag from the zone config to the NAT cross-zone allowance policy. I never saw a config example on the net which would suggest to set masquerading in the policy file, but it seems to work flawless. Cheers, Manfred
HTH -- Till
On Fri, Sep 13, 2024 at 11:56 AM Manfred Schwarb <manfred99@gmx.ch> wrote:
I never saw a config example on the net which would suggest to set masquerading in the policy file, but it seems to work flawless.
Modern firewalld only works with policies internally. Zone definition is converted to policy definition. Due to historical quirks and legacy one zone actually results in 4! internal policies.
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
Manfred Schwarb -
Till Dörges