sfw2 to firewalld conversion
Carlos was right, it is ancient news - the script is dated 2016. I guess it is well off-topic too, but at least it is SUSE related :-) I needed a bit of a distraction, I've been working on a website, so after dinner I installed the migration script on my tw64 test box, along with firewalld. If need be, I can wipe the whole slate clean. After starting firewalld (with an empty config I presume), I tried the first run of susefirewall2-to-firewalld. It took 5m49s - seemed to spend much of it with a whole slew of icmps. Two initial comments - after looking at the output - the conversion script isn't quite ipv6 aware: INFO: RICH: Adding rich rule="rule family=ipv4 source address=fe80::/64 port port=5353 protocol=udp accept" to zone="ext" INFO: RICH: Adding rich rule="rule family=ipv4 source address=fc00::/64 port port=5353 protocol=udp accept" to zone="ext" INFO: RICH: Adding rich rule="rule family=ipv4 source address=fe80::/64 port port=5353 protocol=udp accept" to zone="int" It does however seem to understand your "from:to": port-range syntax: INFO: Adding port(s)="30000-30010/tcp" to zone="external" INFO: Adding port(s)="4664/tcp" to zone="external" INFO: Adding port(s)="427/tcp" to zone="external" INFO: Adding port(s)="5060-5100/udp" to zone="external" -- Per Jessen, Zürich (14.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Carlos was right, it is ancient news - the script is dated 2016. I guess it is well off-topic too, but at least it is SUSE related :-)
I needed a bit of a distraction, I've been working on a website, so after dinner I installed the migration script on my tw64 test box, along with firewalld. If need be, I can wipe the whole slate clean.
After starting firewalld (with an empty config I presume), I tried the first run of susefirewall2-to-firewalld.
It took 5m49s - seemed to spend much of it with a whole slew of icmps.
My first attempt to run with commit died after 3minutes - DEBUG: Executing: firewall-cmd --zone=external --add-service=h323hostcall Error: INVALID_SERVICE: h323hostcall FIREWALLD ERROR: Command 'firewall-cmd ' failed Next, after removing references to 'h323hostcall', it failed again: DEBUG: Executing: firewall-cmd --zone=external --add-rich-rule=rule family=ipv4 source address=192.168.1.0/24 port port=nfs protocol=_rpc_ accept Error: INVALID_PROTOCOL: _rpc_ FIREWALLD ERROR: Command 'firewall-cmd ' failed I guess you left out some bits of your config ? I'll check back tomorrow, going to go and watch telly. -- Per Jessen, Zürich (14.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 21:06, Per Jessen wrote:
Per Jessen wrote:
Carlos was right, it is ancient news - the script is dated 2016. I guess it is well off-topic too, but at least it is SUSE related :-)
I suspect that there are quite a bunch of people out there that never did the change from SuSEfirewall2 to firewalld, as there was no need. The former was to be included (and "supported") in the entire 15.x series, so there was no hurry to migrate.
I needed a bit of a distraction, I've been working on a website, so after dinner I installed the migration script on my tw64 test box, along with firewalld. If need be, I can wipe the whole slate clean.
After starting firewalld (with an empty config I presume), I tried the first run of susefirewall2-to-firewalld.
Hum. The starting point is with SuSEfirewall enabled and running, not firewalld.
It took 5m49s - seemed to spend much of it with a whole slew of icmps.
My first attempt to run with commit died after 3minutes -
DEBUG: Executing: firewall-cmd --zone=external --add-service=h323hostcall Error: INVALID_SERVICE: h323hostcall FIREWALLD ERROR: Command 'firewall-cmd ' failed
Next, after removing references to 'h323hostcall', it failed again:
DEBUG: Executing: firewall-cmd --zone=external --add-rich-rule=rule family=ipv4 source address=192.168.1.0/24 port port=nfs protocol=_rpc_ accept Error: INVALID_PROTOCOL: _rpc_ FIREWALLD ERROR: Command 'firewall-cmd ' failed
I guess you left out some bits of your config ? I'll check back tomorrow, going to go and watch telly.
No, those are "native" parts on SuSEfirewall2 system. I have these: cer@Telcontar:~> rpm -qa | grep -i firewall firewall-macros-0.9.3-150400.8.9.1.noarch susefirewall2-to-firewalld-0.0.4-3.9.1.noarch firewalld-lang-0.9.3-150400.8.9.1.noarch firewall-config-0.9.3-150400.8.9.1.noarch yast2-firewall-4.4.3-150400.1.8.noarch firewalld-0.9.3-150400.8.9.1.noarch SuSEfirewall2-3.6.378-1.33.noarch python3-firewall-0.9.3-150400.8.9.1.noarch cer@Telcontar:~> I suspect you miss the macros. I did forget to include the custom script, though. Wait, looking again, I see you are doing the test on TW. That will not work, it needs Leap. Parts of sfw2 were removed because they were not needed, precisely the parts that do clever things like supporting NFS4 (firewalld was said it would work with nfs4). -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
After starting firewalld (with an empty config I presume), I tried the first run of susefirewall2-to-firewalld.
Hum. The starting point is with SuSEfirewall enabled and running, not firewalld.
"SuSEfirewall2 enabled and running" means a load of iptables rules loaded, that is all. There is nothing "enabled" nor "running". Firewalld is supposed to be running, otherwise the migration script cannot interface with it for making changes.
I guess you left out some bits of your config ? I'll check back tomorrow, going to go and watch telly.
No, those are "native" parts on SuSEfirewall2 system.
I have these:
cer@Telcontar:~> rpm -qa | grep -i firewall firewall-macros-0.9.3-150400.8.9.1.noarch susefirewall2-to-firewalld-0.0.4-3.9.1.noarch firewalld-lang-0.9.3-150400.8.9.1.noarch firewall-config-0.9.3-150400.8.9.1.noarch yast2-firewall-4.4.3-150400.1.8.noarch firewalld-0.9.3-150400.8.9.1.noarch SuSEfirewall2-3.6.378-1.33.noarch python3-firewall-0.9.3-150400.8.9.1.noarch cer@Telcontar:~>
I suspect you miss the macros.
If they were not automagically pulled in, that is quite likely. I was going to check, but in the meantime my connection to office24 was dropped and I cannot reconnect :-)
I did forget to include the custom script, though.
Okay.
Wait, looking again, I see you are doing the test on TW. That will not work, it needs Leap. Parts of sfw2 were removed because they were not needed, precisely the parts that do clever things like supporting NFS4 (firewalld was said it would work with nfs4).
That is gobbledegook - why would the _conversion_ not work? I don't care about the end-result. If it makes you happy, I'll try Leap instead, but I doubt if anything was "removed" from sfw2 - why would anyone make changes to a script that has been deprecated for years? I'll run a diff when I get installed on my leap test system. -- Per Jessen, Zürich (12.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
I guess you left out some bits of your config ? I'll check back tomorrow, going to go and watch telly.
[snip]
I suspect you miss the macros.
tl;dr - conversion seems to go fine, albeit with minor hiccups and with no host-specific rules. ------------- I have now installed firewall-macros. Fyi, I do see a comment in the process: INFO: SuSEfirewall2 is not installed. Will attempt to migrate only based on the old configuration file Clearly nothing much to worry about. I removed the ipv6 references and the non-existent vmnet interfaces. The first dry-run went fine. Hmm, the commit run aborted with: Error: INVALID_SERVICE: h323hostcall FIREWALLD ERROR: Command 'firewall-cmd ' failed Okay, removed. Re-running. Error: INVALID_PROTOCOL: _rpc_ FIREWALLD ERROR: Command 'firewall-cmd ' failed There is a comment in the config: "The special value _rpc_ is recognized as protocol", but that doesn't seem to work. Removing that too - you only have it for accepting NFS traffic on two ranges, 192.168.1.0/24 and 192.168.74/24. Should be easy to re-add manually. Next run - went fine, completed in 9m41s. DEBUG: firewall-cmd --zone=external --remove-service=mdns DEBUG: firewall-cmd --zone=external --remove-service=sip DEBUG: firewall-cmd --zone=external --remove-service=slp DEBUG: firewall-cmd --zone=external --remove-port=427/tcp DEBUG: firewall-cmd --zone=external --remove-port=4664/tcp DEBUG: firewall-cmd --zone=external --remove-port=30000-30010/tcp DEBUG: firewall-cmd --zone=external --remove-port=427/udp DEBUG: firewall-cmd --zone=external --remove-port=4667/udp DEBUG: firewall-cmd --zone=external --remove-port=4674/udp DEBUG: firewall-cmd --zone=external --remove-port=5060-5100/udp DEBUG: firewall-cmd --zone=external --remove-interface=eth0 DEBUG: firewall-cmd --zone=external --add-interface=eth0 DEBUG: firewall-cmd --zone=external --add-port=30000-30010/tcp DEBUG: firewall-cmd --zone=external --add-port=4664/tcp DEBUG: firewall-cmd --zone=external --add-port=427/tcp DEBUG: firewall-cmd --zone=external --add-port=5060-5100/udp DEBUG: firewall-cmd --zone=external --add-port=427/udp DEBUG: firewall-cmd --zone=external --add-port=4674/udp DEBUG: firewall-cmd --zone=external --add-port=4667/udp DEBUG: firewall-cmd --zone=external --add-service=sip DEBUG: firewall-cmd --zone=external --add-service=mdns DEBUG: firewall-cmd --zone=external --add-service=slp (the rest were all about icmp). Listing the zones, looks good, but I notice a complete absence of your host-specific rules from FW_TRUSTED_NETS. Next, I also noticed that no iptables rules were added at all - ah, I need to configure firewalld to use iptables :-) -- Per Jessen, Zürich (13.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Per Jessen wrote:
I guess you left out some bits of your config ? I'll check back tomorrow, going to go and watch telly.
[snip]
I suspect you miss the macros.
tl;dr - conversion seems to go fine, albeit with minor hiccups and with no host-specific rules.
I also seem to have ended up with a firewall that doesn't accept ssh traffic? Hmm, there is no /etc/sysconfig/susefirewall.d/ for other packages to drop their configs into. Okay, maybe you're right, I have to try Leap instead. It looks like sfw2 is fine, but that other packages have (obviously) stopped supporting it. -- Per Jessen, Zürich (13.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Wait, looking again, I see you are doing the test on TW. That will not work, it needs Leap. Parts of sfw2 were removed because they were not needed, precisely the parts that do clever things like supporting NFS4 (firewalld was said it would work with nfs4).
That is gobbledegook - why would the _conversion_ not work?
Well, I have no explanation, but it certainly looks very different on Leap, with sfw2 installed (vanilla config, but not enabled or running). On my first attempt, no issues with _rpc_ or h323whatever and I'm seeing your boatload of rich rules being added too. Runtime 14minutes. It seems to me that the migration script ought to _insist_ on sfw2 being installed. -- Per Jessen, Zürich (14.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-01 10:50, Per Jessen wrote:
Per Jessen wrote:
Wait, looking again, I see you are doing the test on TW. That will not work, it needs Leap. Parts of sfw2 were removed because they were not needed, precisely the parts that do clever things like supporting NFS4 (firewalld was said it would work with nfs4).
That is gobbledegook - why would the _conversion_ not work?
Well, I have no explanation, but it certainly looks very different on Leap, with sfw2 installed (vanilla config, but not enabled or running).
On my first attempt, no issues with _rpc_ or h323whatever and I'm seeing your boatload of rich rules being added too. Runtime 14minutes.
It seems to me that the migration script ought to _insist_ on sfw2 being installed.
Yes, of course SUSEfirewall2 has to be installed and "running", in a manner of speaking. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-01 10:50, Per Jessen wrote:
Per Jessen wrote:
Wait, looking again, I see you are doing the test on TW. That will not work, it needs Leap. Parts of sfw2 were removed because they were not needed, precisely the parts that do clever things like supporting NFS4 (firewalld was said it would work with nfs4).
That is gobbledegook - why would the _conversion_ not work?
Well, I have no explanation, but it certainly looks very different on Leap, with sfw2 installed (vanilla config, but not enabled or running).
On my first attempt, no issues with _rpc_ or h323whatever and I'm seeing your boatload of rich rules being added too. Runtime 14minutes.
It seems to me that the migration script ought to _insist_ on sfw2 being installed.
Yes, of course SUSEfirewall2 has to be installed and "running", in a manner of speaking.
I can't really imagine why. The config information ought to be sufficient - it is sufficient to start it up. There is nothing dynamic about it. -- Per Jessen, Zürich (16.3°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Well, I have no explanation, but it certainly looks very different on Leap, with sfw2 installed (vanilla config, but not enabled or running).
On my first attempt, no issues with _rpc_ or h323whatever and I'm seeing your boatload of rich rules being added too. Runtime 14minutes.
Total runtime with '-c' was 24 minutes. I removed the ipv6 bits and the port-ranges (30000-something). Looking at the iptables setup created/committed, it doesn't seem to be complete. I look for e.g. your rules concerning ports 514 or 5060, and I don't find any. None of all the rich rules with specific hosts. Operator error I expect. I cleared out whatever was created and I'm now running the script again, with '-c'. I'll check back in 25min. -- Per Jessen, Zürich (17.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Per Jessen wrote:
Well, I have no explanation, but it certainly looks very different on Leap, with sfw2 installed (vanilla config, but not enabled or running).
On my first attempt, no issues with _rpc_ or h323whatever and I'm seeing your boatload of rich rules being added too. Runtime 14minutes.
Total runtime with '-c' was 24 minutes. I removed the ipv6 bits and the port-ranges (30000-something). Looking at the iptables setup created/committed, it doesn't seem to be complete. I look for e.g. your rules concerning ports 514 or 5060, and I don't find any. None of all the rich rules with specific hosts. Operator error I expect.
I cleared out whatever was created and I'm now running the script again, with '-c'. I'll check back in 25min.
"cleared out" -> I rebooted. This time it worked, I have a comprehensive set of iptables rule, I can't really think of a reason why it didn't work on the first go. However, "--runtime-to-permanent" failed. Hehe, because of the comment I added a few minutes ago. Comment removed - still fails, "zone conflict: eth1". -- Per Jessen, Zürich (16.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-01 08:44, Per Jessen wrote:
Carlos E. R. wrote:
After starting firewalld (with an empty config I presume), I tried the first run of susefirewall2-to-firewalld.
Hum. The starting point is with SuSEfirewall enabled and running, not firewalld.
"SuSEfirewall2 enabled and running" means a load of iptables rules loaded, that is all. There is nothing "enabled" nor "running".
"running" in a manner of speaking.
Firewalld is supposed to be running, otherwise the migration script cannot interface with it for making changes.
No. The script stops SuSEfirewall2, and starts the firewald daemon to insert the rules.
I guess you left out some bits of your config ? I'll check back tomorrow, going to go and watch telly.
No, those are "native" parts on SuSEfirewall2 system.
I have these:
cer@Telcontar:~> rpm -qa | grep -i firewall firewall-macros-0.9.3-150400.8.9.1.noarch susefirewall2-to-firewalld-0.0.4-3.9.1.noarch firewalld-lang-0.9.3-150400.8.9.1.noarch firewall-config-0.9.3-150400.8.9.1.noarch yast2-firewall-4.4.3-150400.1.8.noarch firewalld-0.9.3-150400.8.9.1.noarch SuSEfirewall2-3.6.378-1.33.noarch python3-firewall-0.9.3-150400.8.9.1.noarch cer@Telcontar:~>
I suspect you miss the macros.
If they were not automagically pulled in, that is quite likely. I was going to check, but in the meantime my connection to office24 was dropped and I cannot reconnect :-)
The script warns of that.
I did forget to include the custom script, though.
Okay.
Wait, looking again, I see you are doing the test on TW. That will not work, it needs Leap. Parts of sfw2 were removed because they were not needed, precisely the parts that do clever things like supporting NFS4 (firewalld was said it would work with nfs4).
That is gobbledegook - why would the _conversion_ not work? I don't care about the end-result. If it makes you happy, I'll try Leap instead, but I doubt if anything was "removed" from sfw2 - why would anyone make changes to a script that has been deprecated for years?
It is SuSEfirewall2 which will not run, pieces were removed. That _rpc_ thing and similars.
I'll run a diff when I get installed on my leap test system.
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (2)
-
Carlos E. R. -
Per Jessen