[oS-en] Another SuSEfirewall2 to firewall conversion.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This particular post is rantish. Telcontar:~ # time susefirewall2-to-firewalld -c 2>&1 | tee susefirewall2-to-firewalld_2.2.txt ... Error: INVALID_PORT: 30000:30100 FIREWALLD ERROR: Command 'firewall-cmd ' failed But: /etc/sysconfig/SuSEfirewall2 192.168.1.126,tcp,smtp 192.168.1.126,tcp,imap 192.168.1.126,tcp,imaps\ 192.168.1.126,tcp,ftp 192.168.1.126,tcp,ftp-data 192.168.1.126,tcp,http \ # 192.168.1.126,tcp,30000:30100 \ 192.168.1.126,tcp,nfs 192.168.1.126,udp,sunrpc 192.168.1.126,tcp,rsync \ 192.168.1.127,tcp,smtp 192.168.1.127,tcp,imap 192.168.1.127,tcp,imaps\ 192.168.1.127,tcp,ftp 192.168.1.127,tcp,ftp-data 192.168.1.127,tcp,http \ # 192.168.1.127,tcp,30000:30100 \ 192.168.1.127,tcp,nfs 192.168.1.127,udp,sunrpc 192.168.1.127,tcp,rsync \ The line that triggers the error is commented out! I will delete it, of course. - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE5fhxwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVtLwAnRvBv8Yc6XXRxeW+kxCm f6qp8BajAJ93uud6tgspD2+i1/XPRbVH+8nffQ== =Re/K -----END PGP SIGNATURE-----
Carlos E. R. wrote:
The line that triggers the error is commented out!
No they are not. Those hashes don't do what you expect. They are in a string spanning multiple lines, with continuation characters. Try this script: ------------ CARLOS="word1 \ word2 \ word3" echo $CARLOS --------------- Now add a hash in front of 'word2' and try it again. -- Per Jessen, Zürich (15.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Sun, 30 Apr 2023 16:15:14 +0200 Per Jessen <per@opensuse.org> wrote:
Carlos E. R. wrote:
The line that triggers the error is commented out!
No they are not. Those hashes don't do what you expect. They are in a string spanning multiple lines, with continuation characters.
Interesting question of language design. Is there a separate pre-process pass for comments et al, or does the whole parser run as integrated unit? :)
On 2023-04-30 17:44, Dave Howorth wrote:
On Sun, 30 Apr 2023 16:15:14 +0200 Per Jessen <per@opensuse.org> wrote:
Carlos E. R. wrote:
The line that triggers the error is commented out!
No they are not. Those hashes don't do what you expect. They are in a string spanning multiple lines, with continuation characters.
Interesting question of language design. Is there a separate pre-process pass for comments et al, or does the whole parser run as integrated unit? :)
I know that the syntax seems weird, but AFAIR SuSEfirewall2 worked with that just fine. It also accepted the syntax of the port range like this: 192.168.1.126,tcp,30000:30100 which the conversion script rejects. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 17:44, Dave Howorth wrote:
On Sun, 30 Apr 2023 16:15:14 +0200 Per Jessen <per@opensuse.org> wrote:
Carlos E. R. wrote:
The line that triggers the error is commented out!
No they are not. Those hashes don't do what you expect. They are in a string spanning multiple lines, with continuation characters.
Interesting question of language design. Is there a separate pre-process pass for comments et al, or does the whole parser run as integrated unit? :)
I know that the syntax seems weird, but AFAIR SuSEfirewall2 worked with that just fine.
It probably did, even if it may not have done what you expected. I guess you can check one of your yet-to-be-migrated machines. I expect you'll find an iptables rule that permits that port range. SuSEfirewall2 was/is just a bash script for generating iptables statements based on the variable-based config in /etc/sysconfig/SuSEfirewall2 . Bash is a lot of things, but it is hardly capable of building sophisticated text parsers. If you glance at the code, you'll quickly see it works with blanks and commas, as separators.
It also accepted the syntax of the port range like this: 192.168.1.126,tcp,30000:30100 which the conversion script rejects.
The port syntax of "30000:30100" is perfectly valid for iptables, for specifying a port range. The conversion script is apparently being a little more strict with the parsing. -- Per Jessen, Zürich (15.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2023-04-30 a las 14:31 +0200, Carlos E. R. escribió: I can confirm that the conversion has to be run twice: the first time doesn't work. The command sequence, as documented, is: susefirewall2-to-firewalld susefirewall2-to-firewalld -c firewall-cmd --list-all-zones firewall-cmd --runtime-to-permanent The end of the sequence: ... Telcontar:/etc/firewalld # time firewall-cmd --runtime-to-permanent 2>&1 | tee susefirewall2-to-firewalld_4.txt success real 0m0.330s user 0m0.217s sys 0m0.016s Telcontar:/etc/firewalld # l total 228 drwxr-x--- 8 root root 4096 Apr 30 15:20 ./ drwxr-xr-x 242 root root 16384 Apr 14 22:57 ../ -rw-r--r-- 1 root root 153 Apr 30 15:20 direct.xml -rw------- 1 root root 2745 Apr 30 14:40 firewalld.conf -rw------- 1 root root 2745 Apr 30 11:49 firewalld.conf.old drwxr-x--- 2 root root 4096 Feb 20 06:17 helpers/ drwxr-x--- 2 root root 4096 Feb 20 06:17 icmptypes/ drwxr-x--- 2 root root 4096 Feb 20 06:17 ipsets/ -rw-r--r-- 1 root root 268 Apr 30 15:20 lockdown-whitelist.xml -rw-r--r-- 1 root root 268 Feb 20 06:17 lockdown-whitelist.xml.old drwxr-x--- 2 root root 4096 Apr 30 15:20 policies/ drwxr-x--- 2 root root 4096 Feb 20 06:17 services/ -rw-r--r-- 1 root root 59764 Apr 30 14:32 susefirewall2-to-firewalld_2.3.txt -rw-r--r-- 1 root root 90583 Apr 30 14:40 susefirewall2-to-firewalld_2.4.txt -rw-r--r-- 1 root root 2581 Apr 30 15:19 susefirewall2-to-firewalld_3.4.txt -rw-r--r-- 1 root root 8 Apr 30 15:20 susefirewall2-to-firewalld_4.txt drwxr-x--- 2 root root 4096 Apr 30 15:20 zones/ Telcontar:/etc/firewalld # ls -ltr zones/ total 48 -rw-r--r-- 1 root root 358 Mar 22 2020 external.xml.old -rw-r--r-- 1 root root 293 Apr 30 15:20 dmz.xml -rw-r--r-- 1 root root 299 Apr 30 15:20 block.xml -rw-r--r-- 1 root root 291 Apr 30 15:20 drop.xml -rw-r--r-- 1 root root 191 Apr 30 15:20 docker.xml -rw-r--r-- 1 root root 442 Apr 30 15:20 internal.xml -rw-r--r-- 1 root root 369 Apr 30 15:20 home.xml -rw-r--r-- 1 root root 389 Apr 30 15:20 external.xml -rw-r--r-- 1 root root 311 Apr 30 15:20 work.xml -rw-r--r-- 1 root root 162 Apr 30 15:20 trusted.xml -rw-r--r-- 1 root root 315 Apr 30 15:20 public.xml -rw-r--r-- 1 root root 726 Apr 30 15:20 nm-shared.xml Telcontar:/etc/firewalld # Notice the size of the external.xml file, too small. Then I run the sequence again: susefirewall2-to-firewalld susefirewall2-to-firewalld -c firewall-cmd --list-all-zones firewall-cmd --runtime-to-permanent Capture of the end of the sequence: ... Telcontar:/etc/firewalld # time firewall-cmd --runtime-to-permanent 2>&1 | tee susefirewall2-to-firewalld_14.txt success real 0m0.406s user 0m0.211s sys 0m0.016s Telcontar:/etc/firewalld # ls -ltr zones/ total 124 -rw-r--r-- 1 root root 293 Apr 30 15:20 dmz.xml.old -rw-r--r-- 1 root root 299 Apr 30 15:20 block.xml.old -rw-r--r-- 1 root root 291 Apr 30 15:20 drop.xml.old -rw-r--r-- 1 root root 191 Apr 30 15:20 docker.xml.old -rw-r--r-- 1 root root 442 Apr 30 15:20 internal.xml.old -rw-r--r-- 1 root root 369 Apr 30 15:20 home.xml.old -rw-r--r-- 1 root root 389 Apr 30 15:20 external.xml.old -rw-r--r-- 1 root root 311 Apr 30 15:20 work.xml.old -rw-r--r-- 1 root root 162 Apr 30 15:20 trusted.xml.old -rw-r--r-- 1 root root 315 Apr 30 15:20 public.xml.old -rw-r--r-- 1 root root 726 Apr 30 15:20 nm-shared.xml.old -rw-r--r-- 1 root root 291 Apr 30 18:16 drop.xml -rw-r--r-- 1 root root 191 Apr 30 18:16 docker.xml -rw-r--r-- 1 root root 2136 Apr 30 18:16 dmz.xml -rw-r--r-- 1 root root 299 Apr 30 18:16 block.xml -rw-r--r-- 1 root root 22034 Apr 30 18:16 external.xml -rw-r--r-- 1 root root 369 Apr 30 18:16 home.xml -rw-r--r-- 1 root root 315 Apr 30 18:16 public.xml -rw-r--r-- 1 root root 726 Apr 30 18:16 nm-shared.xml -rw-r--r-- 1 root root 19772 Apr 30 18:16 internal.xml -rw-r--r-- 1 root root 311 Apr 30 18:16 work.xml -rw-r--r-- 1 root root 162 Apr 30 18:16 trusted.xml Telcontar:/etc/firewalld # less zones/external.xml Telcontar:/etc/firewalld # Notice that this second time the file is much bigger. I have full the command sequence saved, if anyone wants it. 673 KB. - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZE6a3Bwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVmhsAniyypawEcJAMT/tc+1pG o5rmhy17AJ0db6klwCC/Te9w+JOofFMCvjFxKQ== =RCGK -----END PGP SIGNATURE-----
Carlos E. R. wrote:
I have full the command sequence saved, if anyone wants it. 673 KB.
bugzilla might want to chew it over. If you want, put your old sfw2 config up on paste.o.o or send it to me by email. I'll be happy to run the conversion here, that is what test systems are for. -- Per Jessen, Zürich (15.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 19:06, Per Jessen wrote:
Carlos E. R. wrote:
I have full the command sequence saved, if anyone wants it. 673 KB.
bugzilla might want to chew it over.
I don't think they will want it, it is years late.
If you want, put your old sfw2 config up on paste.o.o or send it to me by email. I'll be happy to run the conversion here, that is what test systems are for.
Ok, if you want to entertain yourself I will email it to you. Have fun :-) But I suspect the problem can be reproduced with any plain SuSEconfig config. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 19:06, Per Jessen wrote:
Carlos E. R. wrote:
I have full the command sequence saved, if anyone wants it. 673 KB.
bugzilla might want to chew it over.
I don't think they will want it, it is years late.
Oh. I haven't kept track of when we started defaulting to firewalld.
If you want, put your old sfw2 config up on paste.o.o or send it to me by email. I'll be happy to run the conversion here, that is what test systems are for.
Ok, if you want to entertain yourself I will email it to you. Have fun :-)
But I suspect the problem can be reproduced with any plain SuSEconfig config.
I don't have one. -- Per Jessen, Zürich (14.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 19:40, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 19:06, Per Jessen wrote:
Carlos E. R. wrote:
I have full the command sequence saved, if anyone wants it. 673 KB.
bugzilla might want to chew it over.
I don't think they will want it, it is years late.
Oh. I haven't kept track of when we started defaulting to firewalld.
Probably the 15.0 series.
If you want, put your old sfw2 config up on paste.o.o or send it to me by email. I'll be happy to run the conversion here, that is what test systems are for.
Ok, if you want to entertain yourself I will email it to you. Have fun :-)
But I suspect the problem can be reproduced with any plain SuSEconfig config.
I don't have one.
Just install the package, then open ssh. That should be all that is needed. That's on a default install, unless you remove the firewall. Oh, no, the default is firewalld. I don't know how to install SuSEfirewall2 today. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E.R. wrote:
But I suspect the problem can be reproduced with any plain SuSEconfig config.
I don't have one.
Just install the package, then open ssh. That should be all that is needed.
It would take me far too long to study how to do that :-) Still, it seems unlikely for you to have stumbled over a sfw2 conversion issue so late.
That's on a default install, unless you remove the firewall. Oh, no, the default is firewalld. I don't know how to install SuSEfirewall2 today.
zypper in SuSEfirewall2 ? Well, it's only a bash script, if need be I can copy from an old system that might still have it installed. -- Per Jessen, Zürich (14.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 19:56, Per Jessen wrote:
Carlos E.R. wrote:
But I suspect the problem can be reproduced with any plain SuSEconfig config.
I don't have one.
Just install the package, then open ssh. That should be all that is needed.
It would take me far too long to study how to do that :-)
Still, it seems unlikely for you to have stumbled over a sfw2 conversion issue so late.
Maybe not. Maybe it worked, and it has bit-rotten over the years.
That's on a default install, unless you remove the firewall. Oh, no, the default is firewalld. I don't know how to install SuSEfirewall2 today.
zypper in SuSEfirewall2 ? Well, it's only a bash script, if need be I can copy from an old system that might still have it installed.
Maybe. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 19:56, Per Jessen wrote:
Carlos E.R. wrote:
But I suspect the problem can be reproduced with any plain SuSEconfig config.
I don't have one.
Just install the package, then open ssh. That should be all that is needed.
It would take me far too long to study how to do that :-)
Still, it seems unlikely for you to have stumbled over a sfw2 conversion issue so late.
Maybe not. Maybe it worked, and it has bit-rotten over the years.
Bitrot usually happens when something is not keeping up - in this case, there is nothing to keep up with. Presumably enhancements to sfw2 ceased long ago, long before the migration script was conceived. -- Per Jessen, Zürich (14.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-01 09:28, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 19:56, Per Jessen wrote:
Carlos E.R. wrote:
But I suspect the problem can be reproduced with any plain SuSEconfig config.
I don't have one.
Just install the package, then open ssh. That should be all that is needed.
It would take me far too long to study how to do that :-)
Still, it seems unlikely for you to have stumbled over a sfw2 conversion issue so late.
Maybe not. Maybe it worked, and it has bit-rotten over the years.
Bitrot usually happens when something is not keeping up - in this case, there is nothing to keep up with. Presumably enhancements to sfw2 ceased long ago, long before the migration script was conceived.
Maybe I should report the issue, just for the record, without much expectations. After all, the script is included in the distro, and I know for certain there are people that haven't migrated yet. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
* Carlos E.R. <robin.listas@gmx.es> [04-30-23 13:46]:
On 2023-04-30 19:40, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 19:06, Per Jessen wrote:
Carlos E. R. wrote:
I have full the command sequence saved, if anyone wants it. 673 KB.
bugzilla might want to chew it over.
I don't think they will want it, it is years late.
Oh. I haven't kept track of when we started defaulting to firewalld.
Probably the 15.0 series.
I have a 14.2 server with firewalld -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
Per Jessen wrote:
Carlos E. R. wrote:
I have full the command sequence saved, if anyone wants it. 673 KB.
bugzilla might want to chew it over.
If you want, put your old sfw2 config up on paste.o.o or send it to me by email. I'll be happy to run the conversion here, that is what test systems are for.
I can confirm that the conversion only needs to be run once, the first time works fine. :-) I frankly suspect some Heisenbug - I do not understand why I am suddenly no longer seeing "ZONE_CONFLICT: eth1" RT_TO_PERM_FAILED when trying to persist the firewall config. I did do some minor changes to your config - see attached. They really are very minor, some even pointless because the migration ignores them anyway. (custom rules, extra interfaces) I think the sfw2 migration script has ample room for improvement, but as a quick work-around, it seems to do the job. -- Per Jessen, Zürich (15.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-02 13:54, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
I have full the command sequence saved, if anyone wants it. 673 KB.
bugzilla might want to chew it over.
If you want, put your old sfw2 config up on paste.o.o or send it to me by email. I'll be happy to run the conversion here, that is what test systems are for.
I can confirm that the conversion only needs to be run once, the first time works fine. :-)
You had to do multiple runs, because of errors.
I frankly suspect some Heisenbug - I do not understand why I am suddenly no longer seeing "ZONE_CONFLICT: eth1" RT_TO_PERM_FAILED when trying to persist the firewall config.
I did do some minor changes to your config - see attached. They really are very minor, some even pointless because the migration ignores them anyway. (custom rules, extra interfaces)
I got internal.xml covering vmnet1 and vmnet8
I think the sfw2 migration script has ample room for improvement, but as a quick work-around, it seems to do the job.
It does the job, but on two machines I had to run the sequence twice. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-02 13:54, Per Jessen wrote:
Per Jessen wrote:
Carlos E. R. wrote:
I have full the command sequence saved, if anyone wants it. 673 KB.
bugzilla might want to chew it over.
If you want, put your old sfw2 config up on paste.o.o or send it to me by email. I'll be happy to run the conversion here, that is what test systems are for.
I can confirm that the conversion only needs to be run once, the first> time works fine. :-)
You had to do multiple runs, because of errors.
Umm, no I didn't - I _did_ do multiple runs, with reboots in betweeen, to make sure I always started from the same point. There were no errors.
I frankly suspect some Heisenbug - I do not understand why I am suddenly no longer seeing "ZONE_CONFLICT: eth1" RT_TO_PERM_FAILED when trying to persist the firewall config.
I did do some minor changes to your config - see attached. They really are very minor, some even pointless because the migration ignores them anyway. (custom rules, extra interfaces)
I got internal.xml covering vmnet1 and vmnet8
Afaict, the migration script works with existing interfaces only, there was probably no reason to remove those vmnet interfaces. I got external.xml covering eth3, eth4, eth5 and eth6 :-)
I think the sfw2 migration script has ample room for improvement, but as a quick work-around, it seems to do the job.
It does the job, but on two machines I had to run the sequence twice.
Well, maybe something odd in your environment or perhaps the old fashioned - garbage in, garbage out. With those few changes I mentioned, the "single-pass" conversion is reproducable here, again and again. Also when I re-added your vmnet1 and vmnet8 and re-enabled the source-quench icmp. The conversion took 31 minutes though :-) -- Per Jessen, Zürich (20.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-30 14:31, Carlos E. R. wrote: Hi, The ftp service contemplates only port 21
cer@Telcontar:/usr/lib/firewalld/services> cat ftp.xml <?xml version="1.0" encoding="utf-8"?> <service> <short>FTP</short> <description>FTP is a protocol used for remote file transfer. If you plan to make your FTP server publicly available, enable this option. You need the vsftpd package installed for this option to be useful.</description> <port protocol="tcp" port="21"/> <helper name="ftp"/> </service> cer@Telcontar:/usr/lib/firewalld/services>
cer@Telcontar:/usr/lib/firewalld/services> grep " 20/" /etc/services ftp-data 20/tcp # File Transfer [Default Data] [Jon_Postel] ftp-data 20/udp # File Transfer [Default Data] [Jon_Postel] ftp-data 20/sctp # FTP [Randall_Stewart] [RFC4960] cer@Telcontar:/usr/lib/firewalld/services>
Port 20 is used for data transfer, in active mode, so firewalld doesn't support "active ftp", AFAICS. Or is it passive? this article says it is passive which fails: <https://www.getpagespeed.com/server-setup/firewalld-ftp-rule-allow-access-ftp-service-centos-7> <https://serverfault.com/questions/634594/allowing-passive-ftp-connections-in-firewalld-centos-7> <https://docs.deistercloud.com/content/Tutorials.100/Linux.80/Configuration.20/Install%20FTP%20service.12.xml?embedded=true> I heard of this long ago, I thought it would have been solved by now :-( Probably there will be problems with nfs4 as well. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-30 14:31, Carlos E. R. wrote:
Hi,
The ftp service contemplates only port 21
Port 20 is used for data transfer, in active mode, so firewalld doesn't support "active ftp", AFAICS. Or is it passive? this article says it is passive which fails:
I heard of this long ago, I thought it would have been solved by now :-(
ftp is really outdated. I suppose some hosting services still offer it (we do too), but it is not a function/protocol I would expect to see much development in.
Probably there will be problems with nfs4 as well.
nfs is meant for trusted networks. -- Per Jessen, Zürich (16.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-01 15:37, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-30 14:31, Carlos E. R. wrote:
Hi,
The ftp service contemplates only port 21
Port 20 is used for data transfer, in active mode, so firewalld doesn't support "active ftp", AFAICS. Or is it passive? this article says it is passive which fails:
I heard of this long ago, I thought it would have been solved by now :-(
ftp is really outdated. I suppose some hosting services still offer it (we do too), but it is not a function/protocol I would expect to see much development in.
No, but it is there. It is the firewall which doesn't support it. SuSEfirewall2 did.
Probably there will be problems with nfs4 as well.
nfs is meant for trusted networks.
Sure, but I have to use it. Under IPv4, the LAN is secure. It is basically the same problem: firewalld doesn't support dynamic port assignments. There are kernel modules for this which the tool doesn't support. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-01 15:37, Per Jessen wrote:
ftp is really outdated. I suppose some hosting services still offer it (we do too), but it is not a function/protocol I would expect to see much development in.
No, but it is there. It is the firewall which doesn't support it.
This for you using an ftp client to access an external ftp service?
Probably there will be problems with nfs4 as well.
nfs is meant for trusted networks.
Sure, but I have to use it. Under IPv4, the LAN is secure.
I am only saying - don't expect everything to work when you are not adhering to the commonly accepted conditions. -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-01 15:54, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:37, Per Jessen wrote:
ftp is really outdated. I suppose some hosting services still offer it (we do too), but it is not a function/protocol I would expect to see much development in.
No, but it is there. It is the firewall which doesn't support it.
This for you using an ftp client to access an external ftp service?
No, I have an ftp server in this machine. LAN only.
Probably there will be problems with nfs4 as well.
nfs is meant for trusted networks.
Sure, but I have to use it. Under IPv4, the LAN is secure.
I am only saying - don't expect everything to work when you are not adhering to the commonly accepted conditions.
What commonly accepted conditions am I not adhering to? I run both nfs server and clients in all my computers in my LAN, and I do want to keep all my machines with an active firewall. This is pretty normal. You can seek the archives and you will see people complaining about firewalld not working in this very common scenario. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E.R. wrote:
On 2023-05-01 15:54, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:37, Per Jessen wrote:
ftp is really outdated. I suppose some hosting services still offer it (we do too), but it is not a function/protocol I would expect to see much development in.
No, but it is there. It is the firewall which doesn't support it.
This for you using an ftp client to access an external ftp service?
No, I have an ftp server in this machine. LAN only.
Aha okay - well, that works fine, certainly with iptables. I would not necessarily expect firewalld to directly support that. Well, I would not be surprised if it doesn't.
I am only saying - don't expect everything to work when you are not adhering to the commonly accepted conditions.
What commonly accepted conditions am I not adhering to?
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
I run both nfs server and clients in all my computers in my LAN, and I do want to keep all my machines with an active firewall. This is pretty normal.
I disagree. If the network is trusted, what is the point of a firewall? -- Per Jessen, Zürich (17.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Mon, 01 May 2023 17:37:25 +0200 Per Jessen <per@opensuse.org> wrote:
Carlos E.R. wrote:
On 2023-05-01 15:54, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:37, Per Jessen wrote:
ftp is really outdated. I suppose some hosting services still offer it (we do too), but it is not a function/protocol I would expect to see much development in.
No, but it is there. It is the firewall which doesn't support it.
This for you using an ftp client to access an external ftp service?
No, I have an ftp server in this machine. LAN only.
Aha okay - well, that works fine, certainly with iptables. I would not necessarily expect firewalld to directly support that. Well, I would not be surprised if it doesn't.
I am only saying - don't expect everything to work when you are not adhering to the commonly accepted conditions.
What commonly accepted conditions am I not adhering to?
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
I run both nfs server and clients in all my computers in my LAN, and I do want to keep all my machines with an active firewall. This is pretty normal.
I disagree. If the network is trusted, what is the point of a firewall?
NFS in particular is often performance sensitive since programs aren't written to expect it. So added cycles due to a firewall are a non-starter in a lot of use cases, quite apart from any other reasons.
* Dave Howorth <dave@howorth.org.uk> [05-01-23 11:57]:
On Mon, 01 May 2023 17:37:25 +0200 Per Jessen <per@opensuse.org> wrote: ...
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
I run both nfs server and clients in all my computers in my LAN, and I do want to keep all my machines with an active firewall. This is pretty normal.
I disagree. If the network is trusted, what is the point of a firewall?
NFS in particular is often performance sensitive since programs aren't written to expect it. So added cycles due to a firewall are a non-starter in a lot of use cases, quite apart from any other reasons.
I experienced "difficulties" with nfs/nfs4 and switched to sshfs and haven't looked back. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2023-05-01 17:55, Dave Howorth wrote:
On Mon, 01 May 2023 17:37:25 +0200 Per Jessen <> wrote:
Carlos E.R. wrote:
On 2023-05-01 15:54, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 15:37, Per Jessen wrote:
ftp is really outdated. I suppose some hosting services still offer it (we do too), but it is not a function/protocol I would expect to see much development in.
No, but it is there. It is the firewall which doesn't support it.
This for you using an ftp client to access an external ftp service?
No, I have an ftp server in this machine. LAN only.
Aha okay - well, that works fine, certainly with iptables. I would not necessarily expect firewalld to directly support that. Well, I would not be surprised if it doesn't.
I am only saying - don't expect everything to work when you are not adhering to the commonly accepted conditions.
What commonly accepted conditions am I not adhering to?
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
I run both nfs server and clients in all my computers in my LAN, and I do want to keep all my machines with an active firewall. This is pretty normal.
I disagree. If the network is trusted, what is the point of a firewall?
I don't see the point in not using it.
NFS in particular is often performance sensitive since programs aren't written to expect it. So added cycles due to a firewall are a non-starter in a lot of use cases, quite apart from any other reasons.
I have been using NFS for decades across a firewall on each computer, no issues. Works fine with SuSEfirewall2. firewalld supports up to version 3 of nfs, it has problems with version 4. It is the fault of firewalld, not of iptables or whatever. The problem is that it doesn't know about the dynamic ports it opens. The hack is to make the server use a small range of ports and independently open them. See the last post. <https://unix.stackexchange.com/questions/243756/nfs-servers-and-firewalld> For openSUSE: <https://unix.stackexchange.com/questions/607268/how-do-i-open-firewall-for-nfs-server-on-opensuse-tumbleweed> Another post says to just open port 2049/tcp instead. <https://subscription.packtpub.com/book/networking-&-servers/9781785287831/6/ch06lvl1sec50/hosting-nfsv4-behind-a-firewall> Can't read the full post, though :-/ But indeed, nfs.xml opens port 2049. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Mon, May 1, 2023 at 11:11 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
I have been using NFS for decades across a firewall on each computer, no issues. Works fine with SuSEfirewall2.
SuSEfirewall2 queried portmapper and opened ports registered by specific service. Which means it works only if SuSEfilrewall2 is started after the service in question has been started. It works for NFS on boot because SuSEfirewall2 was forced to start after the NFS server and hence after the network was up. But if you restart the NFS service and it happens to pick up different ports, it stops working. And you have a window after your system is reachable over the network but the firewall is yet not active. So yes, it sort of worked ...
firewalld supports up to version 3 of nfs, it has problems with version 4. It is the fault of firewalld, not of iptables or whatever.
What sort of problems? NFSv4 needs one and only port, there are no dynamic ports to open. If anything, firewalld should be having problems with NFSv3 unless you force a static port for mountd.
The problem is that it doesn't know about the dynamic ports it opens.
So how could it possibly support NFSv3 which relies on dynamic ports?
The hack is to make the server use a small range of ports and independently open them.
See the last post. <https://unix.stackexchange.com/questions/243756/nfs-servers-and-firewalld>
You mean the post where he first adds ports 2049 and 20048 as services then adds ports 2049 and some mysterious "default" port 4001 explicitly and then suddenly it turns out that his mountd is using neither of these ports and he adds yet another port for mountd (in spite of adding "mountd" service previously)? Oh yes, this is certainly a very trustworthy source of information.
For openSUSE:
Another post says to just open port 2049/tcp instead.
Yes, this is the only port needed for NFSv4 between client and server (unless you changed the defaults).
On 2023-05-02 09:47, Andrei Borzenkov wrote:
On Mon, May 1, 2023 at 11:11 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
I have been using NFS for decades across a firewall on each computer, no issues. Works fine with SuSEfirewall2.
SuSEfirewall2 queried portmapper and opened ports registered by specific service. Which means it works only if SuSEfilrewall2 is started after the service in question has been started. It works for NFS on boot because SuSEfirewall2 was forced to start after the NFS server and hence after the network was up. But if you restart the NFS service and it happens to pick up different ports, it stops working. And you have a window after your system is reachable over the network but the firewall is yet not active.
So yes, it sort of worked ...
firewalld supports up to version 3 of nfs, it has problems with version 4. It is the fault of firewalld, not of iptables or whatever.
What sort of problems? NFSv4 needs one and only port, there are no dynamic ports to open. If anything, firewalld should be having problems with NFSv3 unless you force a static port for mountd.
Then perhaps I got it wrong, 4 worked, and 3 had problems. Then that is good news. I found an old post in our mail list: ]>> Warning: firewalld does not support NFS below V4, because it does ]>> not support NFSv3 and ypserv/ypbind, random ports. ]> ]> if you want to change to firewalld: ]> ]> install ]> firewalld-rpcbind-helper ]> ]> firewall-rpc-helper.py --help ]> ]> and follow the examples. ]> this will change /etc/sysconfig/nfs for static nfs ]> maybe if not inside this file present, add the line: ]> RQUOTAD_PORT="" ]> (to make sure all rules are applied (maybe for later use of this ]> service) ]> ]> after that: ]> yast firewall ]> remove nfs ]> remove nfs3 ]> add the new created nfs-server-static ]> ]> and of course you have to uninstall susefirewall2 before... Meanwhile, nfs mounts between both migrated machines is working, which is fantastic. They are all using nfs4, I see. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 5/1/23 08:37, Per Jessen wrote:
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
We use NFS with the host-based firewalls running, both SuSEfirewall2 and firewalld.
I run both nfs server and clients in all my computers in my LAN, and I do want to keep all my machines with an active firewall. This is pretty normal. I disagree. If the network is trusted, what is the point of a firewall?
It's good security practice, we've been doing it for decades. Indeed, that we could do that was once justification to not use Windows! It protects well-behaved Linux boxes from those rude and insecure Windows cesspools on the same subnet. Regards, Lew
Lew Wolfgang wrote:
On 5/1/23 08:37, Per Jessen wrote:
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
We use NFS with the host-based firewalls running, both SuSEfirewall2 and firewalld.
Like I have suggested before, you and Carlos are kindred spirits :-)
I disagree. If the network is trusted, what is the point of a firewall?
It's good security practice, we've been doing it for decades.
I'm sorry, what is "good security practice"? not trusting your trusted network?
Indeed, that we could do that was once justification to not use Windows! It protects well-behaved Linux boxes from those rude and insecure Windows cesspools on the same subnet.
In other words, you don't have a trusted network, hence the need for firewalls. Makes perfect sense. -- Per Jessen, Zürich (11.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 5/1/23 10:28, Per Jessen wrote:
It's good security practice, we've been doing it for decades. I'm sorry, what is "good security practice"? not trusting your trusted network?
Networks that host Windows boxes can never be trusted! There are just too many malware vectors targeting Windows.
Indeed, that we could do that was once justification to not use Windows! It protects well-behaved Linux boxes from those rude and insecure Windows cesspools on the same subnet. In other words, you don't have a trusted network, hence the need for firewalls. Makes perfect sense.
I guess you have a Maginot Line kind of a network, Per. A crunchy crust with a soft center? Defense in depth is a well recognized method for protecting your assets. See here for a description: https://www.fortinet.com/resources/cyberglossary/defense-in-depth We've been doing it since 1986 when I set up our first IP network with Sun Microsystems boxes. Alas, I did have my failures though. We were smitten by the Morris Worm in 1988. Our connection to the outside was via a 19.2-KBaud SLIP connection at that time. You might recall that the vector for the Worm was the "finger" protocol. Then, I was compromised by a flaw in ssh vers 1.2 around 2001. There was a hole in the host-based firewall for port 22. We increased the depth of our defense after that one. Regards, Lew
On 2023-05-01 20:02, Lew Wolfgang wrote:
On 5/1/23 10:28, Per Jessen wrote:
It's good security practice, we've been doing it for decades. I'm sorry, what is "good security practice"? not trusting your trusted network?
Networks that host Windows boxes can never be trusted! There are just too many malware vectors targeting Windows.
Indeed, that we could do that was once justification to not use Windows! It protects well-behaved Linux boxes from those rude and insecure Windows cesspools on the same subnet. In other words, you don't have a trusted network, hence the need for firewalls. Makes perfect sense.
I guess you have a Maginot Line kind of a network, Per. A crunchy crust with a soft center? Defense in depth is a well recognized method for protecting your assets. See here for a description:
He just doesn't have any Windows machines, so he doesn't realize the need for protection inside. Most successful attacks come from inside. Your network can be fully protected and well cared, then one day one employee is subverted, or suffers an accident, and as there is no protection inside (aka no firewalls inside), the damage rampages free across the company.
https://www.fortinet.com/resources/cyberglossary/defense-in-depth
We've been doing it since 1986 when I set up our first IP network with Sun Microsystems boxes. Alas, I did have my failures though. We were smitten by the Morris Worm in 1988. Our connection to the outside was via a 19.2-KBaud SLIP connection at that time. You might recall that the vector for the Worm was the "finger" protocol. Then, I was compromised by a flaw in ssh vers 1.2 around 2001. There was a hole in the host-based firewall for port 22. We increased the depth of our defense after that one.
Regards, Lew
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-05-01 19:28, Per Jessen wrote:
Lew Wolfgang wrote:
On 5/1/23 08:37, Per Jessen wrote:
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
We use NFS with the host-based firewalls running, both SuSEfirewall2 and firewalld.
Like I have suggested before, you and Carlos are kindred spirits :-)
I disagree. If the network is trusted, what is the point of a firewall?
It's good security practice, we've been doing it for decades.
I'm sorry, what is "good security practice"? not trusting your trusted network?
I would never trust the company network.
Indeed, that we could do that was once justification to not use Windows! It protects well-behaved Linux boxes from those rude and insecure Windows cesspools on the same subnet.
In other words, you don't have a trusted network, hence the need for firewalls. Makes perfect sense.
No, Per, that is normal Windows behaviour and healthy prevention. Any well protected Windows shop can be infected accidentally one day. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-05-01 19:28, Per Jessen wrote:
Lew Wolfgang wrote:
On 5/1/23 08:37, Per Jessen wrote:
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
We use NFS with the host-based firewalls running, both SuSEfirewall2 and firewalld.
Like I have suggested before, you and Carlos are kindred spirits :-)
I disagree. If the network is trusted, what is the point of a firewall?
It's good security practice, we've been doing it for decades.
I'm sorry, what is "good security practice"? not trusting your trusted network?
I would never trust the company network.
I'm sorry, where do you fit in to this? Are you the user, the admin, the janitor ?
Indeed, that we could do that was once justification to not use Windows! It protects well-behaved Linux boxes from those rude and insecure Windows cesspools on the same subnet.
In other words, you don't have a trusted network, hence the need for firewalls. Makes perfect sense.
No, Per, that is normal Windows behaviour and healthy prevention. Any well protected Windows shop can be infected accidentally one day.
You don't trust your Windows machines, yet you connect them to your trusted network - thereby compromising it. If you consider that normal behaviour and you wae the admin in charge, you're fired. I suggest you look up what "trusted" means, Carlos. It only comes in two versions. In your own case, you have an untrusted network yet you want to run a trusted service over it. Bonkers. -- Per Jessen, Zürich (11.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-05-02 08:11, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-05-01 19:28, Per Jessen wrote:
Lew Wolfgang wrote:
On 5/1/23 08:37, Per Jessen wrote:
Using NFS across a firewall is not typically done. Clients and servers are all expected to be on a trusted network. It is possible NFSv4 has made changes in this respect, I haven't looked.
We use NFS with the host-based firewalls running, both SuSEfirewall2 and firewalld.
Like I have suggested before, you and Carlos are kindred spirits :-)
I disagree. If the network is trusted, what is the point of a firewall?
It's good security practice, we've been doing it for decades.
I'm sorry, what is "good security practice"? not trusting your trusted network?
I would never trust the company network.
I'm sorry, where do you fit in to this? Are you the user, the admin, the janitor ?
Depends, but above I was thinking as the user.
Indeed, that we could do that was once justification to not use Windows! It protects well-behaved Linux boxes from those rude and insecure Windows cesspools on the same subnet.
In other words, you don't have a trusted network, hence the need for firewalls. Makes perfect sense.
No, Per, that is normal Windows behaviour and healthy prevention. Any well protected Windows shop can be infected accidentally one day.
You don't trust your Windows machines, yet you connect them to your trusted network - thereby compromising it. If you consider that normal behaviour and you wae the admin in charge, you're fired.
I suggest you look up what "trusted" means, Carlos. It only comes in two versions.
In your own case, you have an untrusted network yet you want to run a trusted service over it. Bonkers.
We have different definitions. As all my computers run firewalls, I can connect unknown Windows machines here. If I am suspicious, I switch of or disconnect local machines. In fact, observing the resulting traffic is a tool to know there is something amiss with the Windows machine, so that I can repair it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
participants (7)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
Dave Howorth -
Lew Wolfgang -
Patrick Shanahan -
Per Jessen