LEAP 15.2 upgrade from 15.0: still using SuSEfirewall2?

[OrsoBruno]

Two laptops with 15.2 beta (Gnome), simply connected via cable+switch, one clean install, the other upgraded from 15.0.
By default install all remote ports are closed, so open port 22 in firewall and assign wired-eth0 to home zone in both systems; nevertheless ssh is not possible.
It turns out that the upgraded laptop is still using SuSEfirewall2:

linux-iqba:~ # systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)
linux-iqba:~ # journalctl -b -u firewalld.service
-- Logs begin at Fri 2017-10-20 11:29:08 CEST, end at Wed 2020-04-15 12:30:48 CEST. --
-- No entries --
linux-iqba:~ # journalctl -b -u SuSEfirewall2.service
-- Logs begin at Fri 2017-10-20 11:29:08 CEST, end at Wed 2020-04-15 12:31:02 CEST. --
Apr 15 11:16:23 linux-iqba systemd[1]: Starting SuSEfirewall2 phase 2...
Apr 15 11:16:23 linux-iqba SuSEfirewall2[1610]: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
Apr 15 11:16:23 linux-iqba SuSEfirewall2[1610]: using default zone 'ext' for interface eth0
Apr 15 11:16:23 linux-iqba SuSEfirewall2[1610]: using default zone 'ext' for interface wlan0
Apr 15 11:16:26 linux-iqba SuSEfirewall2[1610]: Firewall rules successfully set
Apr 15 11:16:26 linux-iqba systemd[1]: Started SuSEfirewall2 phase 2.
linux-iqba:~ # systemctl status SuSEfirewall2.service
● SuSEfirewall2.service - SuSEfirewall2 phase 2
   Loaded: loaded (/usr/lib/systemd/system/SuSEfirewall2.service; enabled; vendor preset: disabled)
   Active: active (exited) since Wed 2020-04-15 11:16:26 CEST; 1h 15min ago
  Process: 1610 ExecStart=/usr/sbin/SuSEfirewall2 boot_setup (code=exited, status=0/SUCCESS)
 Main PID: 1610 (code=exited, status=0/SUCCESS)
    Tasks: 0
   CGroup: /system.slice/SuSEfirewall2.service

Apr 15 11:16:23 linux-iqba systemd[1]: Starting SuSEfirewall2 phase 2...
Apr 15 11:16:23 linux-iqba SuSEfirewall2[1610]: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
Apr 15 11:16:23 linux-iqba SuSEfirewall2[1610]: using default zone 'ext' for interface eth0
Apr 15 11:16:23 linux-iqba SuSEfirewall2[1610]: using default zone 'ext' for interface wlan0
Apr 15 11:16:26 linux-iqba SuSEfirewall2[1610]: Firewall rules successfully set
Apr 15 11:16:26 linux-iqba systemd[1]: Started SuSEfirewall2 phase 2.
linux-iqba:~ #

Manually restarting firewalld I eventually got the desired ssh connection working.
Is all that obvious (I’m sort of networking-noob) or is it worth reporting?
Upgrade from 15.0 is still mentioned in the QA-Leap testing spreadsheet, I found nothing related in the Release Notes and SDB pages are mostly outdated or misleading at best IMHO.
Is there a better reference or recommended procedure to switch to firewalld?

[deano_ferrari]

There was a deliberate decision to leave the legacy (SuSefirewall2) firewall in place for those upgrading from openSUSE 15.0, so that the working firewall configuration was preserved.

Refer
https://forums.opensuse.org/showthread.php/529290-can-anyone-provide-a-clear-overview-of-the-move-to-firewalld?p=2852651#post2852651

[deano_ferrari]

This may also be of interest to you
https://en.opensuse.org/Firewalld

[OrsoBruno]

Thanks for immediate reply… I’ll read all and come back with more…

[OrsoBruno]

Useful reading, then realizing that I had no complex config to recover, switching was as simple as stopping and disabling SuSEfirewall2 and enabling firewalld in YaST Services manager.
Using YaST Firewall to configure on both systems:
“home” zone for eth0, default services including ssh, opening port 22 to connect the two testing machines via wired;
“public” zone for wlan0, only dhcpv6-client and no port open, to access the internet via a WiFi router;
I could happily ssh one system to the other and the other way around.

Now comes the funny part. After a reboot of both systems I see:

localhost:~ # firewall-cmd --get-active-zones
public
  interfaces: eth0 wlan0
localhost:~ #

and trying to ssh the other system I get:

beta_bruno@localhost:~> ssh bruno@192.168.0.111
ssh: connect to host 192.168.0.111 port 22: No route to host
beta_bruno@localhost:~>

and something similar from the other system.
Restarting firewalld doesn’t help:

localhost:~ # systemctl restart firewalld
localhost:~ # firewall-cmd --get-active-zones
public
  interfaces: eth0 wlan0
localhost:~ # 

I have to open YaST Firewall again, “Accept”, effectively reloading the firewall configuration I think, and after that I can happily ssh again:

ocalhost:~ # firewall-cmd --get-active-zones
home
  interfaces: eth0
localhost:~ # 

beta_bruno@localhost:~> ssh bruno@192.168.0.111
Password: 
Last login: Wed Apr 15 19:37:09 2020 from 192.168.0.110
Have a lot of fun...
bruno@linux-iqba:~>

If that is the intended behaviour it seems quite counter-intuitive to me; for instance if I reboot the remote system, I’m cutting me out since I have no means of reloading the firewall config from remote.
Or am I missing something?

[deano_ferrari]

@OrsoBruno

Useful reading, then realizing that I had no complex config to recover, switching was as simple as stopping and disabling SuSEfirewall2 and enabling firewalld in YaST Services manager.

Yes, for many that would have been the case at the time they upgraded (15.0 -> 15.1)

I don’t use the YaST firewall GUI, but instead configure with firewall-cmd (CLI) and firewall-config (GUI). The important concept is that you can make runtime configuration changes (with immediate effect), but won’t be saved until ‘runtime-to-permanent’ action is taken…or permanent configuration changes which won’t take effect until firewalld is reloaded.

firewall-cmd

[OrsoBruno]

Thanks, reload + runtime-to-permanent did the trick, now I can ssh as expected after reboot.
Still I think that most inexperienced users try YaST first, so that tool should have a similar effect. Worth a bug report?
Or a clear, simple how-to should be easy to find in general purpose docs (or maybe it is somewhere but I failed to spot it?)
Anyway there is always an opportunity to learn something here…

[deano_ferrari]

@OrsoBruno

Thanks, reload + runtime-to-permanent did the trick, now I can ssh as expected after reboot.
Still I think that most inexperienced users try YaST first, so that tool should have a similar effect. Worth a bug report?
Or a clear, simple how-to should be easy to find in general purpose docs (or maybe it is somewhere but I failed to spot it?)
Anyway there is always an opportunity to learn something here…

The openSUSE documentation is always a good place to start…
https://doc.opensuse.org/documentation/leap/security/html/book.security/cha-security-firewall.html
My experience is many users don’t make the effort to read docs until they really have to, and encounter problems like these.

[OrsoBruno]

@deano_ferrari

The openSUSE documentation is always a good place to start…
https://doc.opensuse.org/documentation/leap/security/html/book.security/cha-security-firewall.html
My experience is many users don’t make the effort to read docs until they really have to, and encounter problems like these.

My bad, I skimmed through the SSH chapter but failed to check the firewall one. Good reference, clear and detailed enough for a first setup.
Interestingly, no mention of the YaST firewall module (maybe not ready yet when the chapter was written?).
Also worth noting that, apparently, YaST did the job on my main Leap 15.1 install but frankly I don’t recall the exact steps I used there, not involving firewall-config (not installed there) nor firewall-cmd anyway.
Some more beta-testing to do in this area apparently, stay tuned for more help requests from me

BTW when I have a problem I usually:
-check the YaST module if there is any;
-check the SDB (mostly outdated and still referring to SuSEfirewall2 this time)
-ask in the Forum (often the easiest and best learning opportunity )
-skim through the Install Guide

The Security Guide is a bit daunting to me so, yes, I only read through it when I’m forced to. Hope this thread will be useful to other people.
Thanks again.

[deano_ferrari]

@OrsoBruno

My bad, I skimmed through the SSH chapter but failed to check the firewall one. Good reference, clear and detailed enough for a first setup.
Interestingly, no mention of the YaST firewall module (maybe not ready yet when the chapter was written?).

Yes, that came later IIRC. In any case the YaST firewall GUI is only for basic needs, and I don’t see that it adds much value. The native firewalld UIs are better IMO.

Also worth noting that, apparently, YaST did the job on my main Leap 15.1 install but frankly I don’t recall the exact steps I used there, not involving firewall-config (not installed there) nor firewall-cmd anyway.

Yes, and I suspect that would be all many need (not all users even have firewalls running on their personal Linux devices).

Some more beta-testing to do in this area apparently, stay tuned for more help requests from me

All good.

BTW when I have a problem I usually:
-check the YaST module if there is any;
-check the SDB (mostly outdated and still referring to SuSEfirewall2 this time)
-ask in the Forum (often the easiest and best learning opportunity )
-skim through the Install Guide

The Security Guide is a bit daunting to me so, yes, I only read through it when I’m forced to. Hope this thread will be useful to other people.
Thanks again.

I’m sure it will be. Thanks for contributing here. That’s what the forums are all about.

[OrsoBruno]

Playing with firewalld trying to make sense of “runtime” and “permanent” configs I got a funny sequence.
In the following,** LT_B** is the “local, client, 15.1” system, linux-iqba is the “remote, host, 15.2 Beta” system under test.
“Remote system under test” has just been rebooted, after having closed port 22 in firewall **but without issuing “firewall-cmd --runtime-to-permanent”.
**

bruno@LT_B:~> ssh 192.168.0.111                                 <<<<<<<<<<<<<<< requesting access to remote host
Password: 
Last login: Thu Apr 16 16:07:44 2020 from localhost
Have a lot of fun...                                                                    <<<<<<<<<<<<<<< OK, logged in, so ssh active but port 22 open after reboot
bruno@linux-iqba:~> su -
Password: 
linux-iqba:~ # firewall-cmd --info-zone=home
home (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  **services: ssh** mdns samba-client dhcpv6-client vnc-server       <<<<<<<<<<<<<<<< OK, ssh active
 ** ports:                                                                                   <<<<<<<<<<<<<<<< ??? no port open? is this just a "runtime" config?**
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
    
**linux-iqba:~ # firewall-cmd --reload                                        <<<<<<<<<<<<<<<< reloading config, next time port 22 should be closed?**
success
linux-iqba:~ # exit
logout
bruno@linux-iqba:~> exit
logout
Connection to 192.168.0.111 closed.
bruno@LT_B:~> ssh 192.168.0.111                                         <<<<<<<<<<<<<<<<< next login attempt
ssh: connect to host 192.168.0.111 port 22: No route to host     <<<<<<<<<<<<<<<<< no route, port 22 is closed, "runtime" config rules
bruno@LT_B:~> 

So after a reboot the “permanent” config rules (and that makes sense) but “firewall-cmd --info-zone=home” reports the last “runtime” config even if it is not currently in effect?
How can I print the configuration that is currently ruling the system since, apparently, both firewall-cmd and YaST-Firewall show the last “runtime config” that was entered but possibly was not saved to a “permanent” state?

[arvidjaar]

@OrsoBruno

  **services: ssh** mdns samba-client dhcpv6-client vnc-server       <<<<<<<<<<<<<<<< OK, ssh active
 ** ports:                                                         <<<<<<<<<<<<<<<< ??? no port open? is this just a "runtime" config?**

There are open ports from service definitions. They are unrelated to “ports” zone configuration item. I do not understand how it is related to being runtime (or not), except that by default frewalld-cmd shows runtime configuration, which is also documented.

“firewall-cmd --info-zone=home” reports the last “runtime” config

There is no such thing as “last runtime config”. There is runtime config (that is currently in effect) and permanent config (that will be applied next time firewalld is restarted or reloaded).

even if it is not currently in effect?

I have no idea what is is supposed to mean. If you imply that firewalld-cmd prints configuration that is different from currently in effect this is a bug. But nothing you have shown so far gives any indication of it.

How can I print the configuration that is currently ruling the system

This is technical forum. Nowhere in firewalld documentation is defined what “ruling” means. There is configuration that is currently effective (runtime) and configuration that is stored on disk and becomes effective nect time firewalld is restarted.

both firewall-cmd and YaST-Firewall show the last “runtime config” that was entered but possibly was not saved to a “permanent” state?

If we omit “last” (which is your own invention) this behavior is pretty well documented and expected.

[OrsoBruno]

I’m trying to understand how ssh and firewall work, something of what I see makes me wonder what I’m missing, sorry if I used incorrect terms.
Let’s reduce to a very basic question: is port 22 (ssh default) open at any given time on my test system?

I reboot the test system, so the “permanent” config should be in use?
Then I try to ssh:

bruno@LT_B:~> ssh 192.168.0.111 
Password:
Last login: Thu Apr 16 16:07:44 2020 from localhost
Have a lot of fun... 
bruno@linux-iqba:~>

login successful via ssh, so port 22 is open, right?
Now I want to check what the system under test “thinks”:

linux-iqba:~ # firewall-cmd --info-zone=home
home (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: ssh mdns samba-client dhcpv6-client vnc-server
  ports:                                                                                   <<<<<<<<<<<<<<<< ??? no port open?
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
    
linux-iqba:~ #

No port explicitly open, so is port 22 open just because it is the default for ssh?
Now, without touching the firewall config myself, I “reload” whatever config the system likes to reload:

linux-iqba:~ # firewall-cmd --reload
success
linux-iqba:~ #

I didn’t touch the firewall config, so is the system reloading the “permanent” config?
If so, if I close the ssh connection I should be able to ssh again, right?

bruno@linux-iqba:~> exit
logout
Connection to 192.168.0.111 closed.
bruno@LT_B:~> ssh 192.168.0.111 
ssh: connect to host 192.168.0.111 port 22: **No route to host **
bruno@LT_B:~>

Now if port 22 were closed, I would get a “No route to host” error, so I guess that reloading the firewall config might have closed port 22.
Or I am missing something and I’m trying to understand what.
If I ask the system with:

linux-iqba:~ # firewall-cmd --info-zone=home

I see no difference.
Port 22 is still the default for ssh (I didn’t change anything there).
And rebooting the system I can ssh again like at the beginning of this post.
So I guess that the system loads different configs during “reboot” and during “firewall reload”, but this is just a guess at the moment, and not a particularly educated one since I have little experience here.
Any comment welcome.

[deano_ferrari]

@OrsoBruno

I’m trying to understand how ssh and firewall work, something of what I see makes me wonder what I’m missing, sorry if I used incorrect terms.
Let’s reduce to a very basic question: is port 22 (ssh default) open at any given time on my test system?

I reboot the test system, so the “permanent” config should be in use?
Then I try to ssh:

bruno@LT_B:~> ssh 192.168.0.111 
Password:
Last login: Thu Apr 16 16:07:44 2020 from localhost
Have a lot of fun... 
bruno@linux-iqba:~>

login successful via ssh, so port 22 is open, right?
Now I want to check what the system under test “thinks”:

linux-iqba:~ # firewall-cmd --info-zone=home
home (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources: 
  services: ssh mdns samba-client dhcpv6-client vnc-server
  ports:                                                                                   <<<<<<<<<<<<<<<< ??? no port open?
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
    
linux-iqba:~ #

The ‘ports’ line just refers to explicit numeric ports configured. For the ‘common’ services, refer to the ‘services’ ouput instead. They are all associated with implied default ports for the respective services. (You can check the service definition XML files in /etc/firewalld/services for yourself.)

No port explicitly open, so is port 22 open just because it is the default for ssh?

Yes.

[deano_ferrari]

So I guess that the system loads different configs during “reboot” and during “firewall reload”, but this is just a guess at the moment, and not a particularly educated one since I have little experience here.
Any comment welcome.

The permanent configuration can be found in /etc/firewalld/zones/ (check the relevant zone file that you’re using), along with the overall config in /etc/firewalld/firewalld.conf

Please review this firewalld introduction…
https://www.linode.com/docs/security/firewalls/introduction-to-firewalld-on-centos/
I’m sure it will clarify all that you need to know.

[OrsoBruno]

@deano_ferrari

Please review this firewalld introduction…
https://www.linode.com/docs/security/firewalls/introduction-to-firewalld-on-centos/
I’m sure it will clarify all that you need to know.

Thanks, that’s an easier read and working through the examples makes many things clear.

@deano_ferrari

The ‘ports’ line just refers to explicit numeric ports configured. For the ‘common’ services, refer to the ‘services’ ouput instead. They are all associated with implied default ports for the respective services. (You can check the service definition XML files in /etc/firewalld/services for yourself.)

Got it and checked on the test system. So adding ssh to a zone opens the default port 22 and I’m good to go, unless I want to ssh over, say, port 2222.
So I’m now able to answer some of my own questions…

@OrsoBruno

Now, without touching the firewall config myself, I “reload” whatever config the system likes to reload:

linux-iqba:~ # firewall-cmd --reload
success
linux-iqba:~ #

I didn’t touch the firewall config, so is the system reloading the “permanent” config?

Yes, “reload” looks for the “permanent” config and loads it, but this is not enough…

If so, if I close the ssh connection I should be able to ssh again, right?

bruno@linux-iqba:~> exit
logout
Connection to 192.168.0.111 closed.
bruno@LT_B:~> ssh 192.168.0.111 
ssh: connect to host 192.168.0.111 port 22: **No route to host **
bruno@LT_B:~>

Now if port 22 were closed, I would get a “No route to host” error, so I guess that reloading the firewall config might have closed port 22.

Wrong guess. Port 22 is open in the firewall config, but for the config to take effect I need to restart the eth0 interface (for instance switch it off and then connect again) or reboot.
Switching off/on the interface in use (eth0 in this case) after each config change/firewall reload makes the system behaviour consistent and understandable, so that was the missing bit.
Re-reading referenced docs I understand that this is intended behaviour, to preserve existing connections or sessions over the same interface.
And I learned “the hard way” that playing with firewall configs on a remote system might lock yourself out unless you know what you are doing (but I’m sure that experienced admins know that very well and in this test the “remote” system was luckily on the same desk).

[deano_ferrari]

@OrsoBruno

Thanks, that’s an easier read and working through the examples makes many things clear.

Got it and checked on the test system. So adding ssh to a zone opens the default port 22 and I’m good to go, unless I want to ssh over, say, port 2222.

It’s easy enough to either
a) define a custom service that is configured with that port…

Add a Service

or

b) to allow TCP port 2222 do

firewall-cmd --permanent --add-port=2222/tcp

[hcvv]

Glancing through this very fast, I get the idea that you think that the “word” ssh has a special meaning. In fact, in this context where one talks about services that are “listening” and allowed or not through a firewall, the string ssh only is a human readable replacement for 22. It is just the same. Has nothing to do with default, it is an alias. Defined already since ages in /etc/services and maybe also in some other, firewalld related, place.

Hope this helps in understanding that when a tool (in this area) says ftp or http or ssh, that is just to make it better understandable for human beings instead of saying 21 or 80 or 22.

These are btw not default portnumbers, they are asigned portnumbers. Asigned by IANA.

You are free to run the ssh protocol using another portnumber. E.g. when you tell your sshd to listen on port number 8080 and then let your ssh client contact that number, that will work. But you will see that port reported by tools like firewalld as http-alt. and you can use http-alt when configuring firewalld. At the most confusing for those that interprete those listings.

[deano_ferrari]

@hcvv

You are free to run the ssh protocol using another portnumber. E.g. when you tell your sshd to listen on port number 8080 and then let your ssh client contact that number, that will work. But you will see that port reported by tools like firewalld as http-alt. and you can use http-alt when configuring firewalld. At the most confusing for those that interprete those listings.

I think the OP understands that…when they hinted about using port 2222 (a common alternative port used for ssh) instead a couple of posts back.

[hcvv]

@deano_ferrari

I think the OP understands that…when they hinted about using port 2222 (a common alternative port used for ssh) instead a couple of posts back.

It may be that my post is completely superfluous (and that would be better), but from of what the OP says I doubted if he all understands it correct.