Firewalld or IPtables?

Support
1

Hi folks. I have a postresql service issue.

I have a postgresql that’s dedicated to serving this database. Its name is server_n.local. I have another machine that needs to talk to it, and its name is server_f_local.

I used firewall-cmd commands on server_n.local to poke a hole into its firewall to add both the service and the port.

$ sudo firewall-cmd --zone=public --permanent --add-service=postgresql			# firewall service allowed
$ sudo firewall-cmd --zone=public --permanent --add-port 5432/tcp		    # firewall port allowed

So I check the ports from that machine:

[Sun Jul 10 20:48:23 user1@server_n ~/rfs] sudo nmap -sS -p 0-6500 localhost
Starting Nmap 7.91 ( https://nmap.org ) at 2022-07-10 20:52 EDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000050s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 6499 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
5432/tcp open  postgresql

Nmap done: 1 IP address (1 host up) scanned in 0.13 seconds

It shows that port 5432 is open. But when I do the same for server_f.local, this is what I see:

Starting Nmap 7.70 ( https://nmap.org ) at 2022-07-10 20:54 EDT
Nmap scan report for server_n.local (192.168.1.23)
Host is up (0.00038s latency).
Not shown: 6499 filtered ports
PORT     STATE  SERVICE
22/tcp   open   ssh
5432/tcp closed postgresql
MAC Address: D0:50:99:87:7B:4A (ASRock Incorporation)

Nmap done: 1 IP address (1 host up) scanned in 40.46 seconds

As you can see, server_f.local shows that port to be closed. I have no idea why this is happening. I currently think I’ve poked a hole (both incoming and outgoing) on server_n.local, and it’s being seen by my workstation and server_f.local as being closed.

How can I fix this? I need my machines to talk to this postgresql database, and the port somehow remains closed. I’ve read that iptables is better to use, and should I be using that instead? That app sounds confusing compared to firewall-cmd.

2

Further research shows that my server is listening on 127.0.0.1 only.

[Sun Jul 10 21:51:05 root@server_n ~] sudo netstat -tunlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      918/sshd: /usr/sbin
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN      929/postmaster
tcp6       0      0 :::22                   :::*                    LISTEN      918/sshd: /usr/sbin
tcp6       0      0 ::1:5432                :::*                    LISTEN      929/postmaster
udp        0      0 127.0.0.1:323           0.0.0.0:*                           836/chronyd
udp6       0      0 ::1:323                 :::*                                836/chronyd

I used nc -lp 5432 in the past to achieve this. Seems I need to take that out and enter this: nc -lp4 5432 --allow 192.168.1.24 but I’m guessing as I don’t know how to remove the first nc instruction.

3

Turns out nc is more for single communications and scripted type stuff, as opposed to a way of making sure a port is constantly listening.

4

is this your third of fourth thread about this now?

5

There is no real iptables in Alma because kernel now has nftables.

6

It keeps changing. The only part of all this that’s giving me hassles is AlmaLinux, so I’m asking.

7

As it turns out, I’ve learned firewalld is a wrapper for both iptables and nptables. Also, the firewall stuff worked, but for some reason the ports are not listening. I can tweak the port open using nc but that’s not a permanent solution. I know I’m missing something, and I have some feelers out.

8

You have been told in your other threads (about this same issue) that a “port” does not listen and firewall does not listen – process does. In your case the process must be ‘postmaster’, the process that postgresql.service does start.

The nc is not a solution, not even a temporary solution. The nc is a totally different program that you can make listen to port ‘5432/tcp’, but when the nc process listens there, then the postmaster cannot – only one process can listen a specific port. Your psql clients cannot talk to nc, they must talk to postmaster.

What you are missing is the correct configuration of postgresql. (That is not Alma-specific; postgresql probably has same config on all platforms.)

9

OK, you’re confusing a couple of things. Not once did I say I was going to use any postgres client through nc. I was using nc to see if I can get any communications, as postgresql.conf was set up to listen on many ports. So the process was working for localhost but not across the LAN. Yes the conf file was set up for the whole LAN.

Second, that communications was turning off. I’m currently measuring that now.

10

Which file(s)?

The postgresql.conf has listen_addresses to set which interfaces are listened. It could have '*' when firewall and authentication limit access.

The authentication is in pg_hba.conf. What did you add there?

11

Yes, postgresql.conf I spend a lot of time in. I had *, which originally broke all listening, then I broke it out to IP4 options (0.0.0.0, localhost4, 192.168.1.23), and now back to *. As for pg_hba.conf:

host    all             user1            192.168.1.4             255.255.255.0    trust
host    all             user1            192.168.1.24            255.255.255.0    md5

It seems to be working now, and still testing nmap results.