funny firewall behavior

Message

leyvi · Post by **leyvi** » Fri Mar 13, 2026 7:48 am

I'm trying to run an SSH server on my desktop. When attempting to access it from other devices, I get the following error message:

Code: Select all

ssh: connect to host 10.x.x.x: port 22: Connection refused

Except that I have port 22 open on my firewall:

Code: Select all

 $ rc-service nftables list
nftables                  |table bridge grumpy_troll {
nftables                  |	chain in_V6 {
nftables                  |		icmpv6 type { 1, 2, 3, 129, 130, 131, 132, 134, 135, 136, 137, 138, 141, 142, 143 } accept
nftables                  |		icmpv6 type 128 limit rate 64/second burst 5 packets log prefix "[br0:ipv6] Received ping: " accept
nftables                  |		icmpv6 type 133 accept
nftables                  |	}
nftables                  |
nftables                  |	chain in_V4 {
nftables                  |		icmp type 8 log prefix "[br0:ipv4] Received ping: "
nftables                  |		ip protocol 1 limit rate 64/second burst 5 packets accept
nftables                  |	}
nftables                  |
nftables                  |	chain input {
nftables                  |		type filter hook input priority -200; policy drop;
nftables                  |		ct state { 0x2, 0x4 } accept
nftables                  |		udp dport { 1714-1764, 1900, 5353, 6881, 7881, 8881, 34197 } accept
nftables                  |		tcp dport { 22, 445, 1714-1764, 1900, 6881, 8096, 25565 } accept
nftables                  |		meta protocol vmap { 0x0800 : jump in_V4, 0x86dd : jump in_V6 }
nftables                  |		iif "lo" accept
nftables                  |		ether type 0x0806 accept
nftables                  |	}
nftables                  |}
nftables                  |table inet master {
nftables                  |	chain in_V6 {
nftables                  |		icmpv6 type { 1, 2, 3, 129, 130, 131, 132, 134, 135, 136, 137, 138, 141, 142, 143 } accept
nftables                  |		icmpv6 type 128 limit rate 16/second burst 5 packets accept
nftables                  |	}
nftables                  |
nftables                  |	chain in_V4 {
nftables                  |		ip protocol 1 limit rate 16/second burst 5 packets accept
nftables                  |	}
nftables                  |
nftables                  |	chain input {
nftables                  |		type filter hook input priority 0; policy drop;
nftables                  |		ct state { 0x2, 0x4 } accept
nftables                  |		udp dport { 1714-1764, 1900, 5353, 6881, 7881, 8881, 34197 } accept
nftables                  |		tcp dport { 22, 445, 1714-1764, 1900, 6881, 8096, 25565 } accept
nftables                  |		meta protocol vmap { 0x0800 : jump in_V4, 0x86dd : jump in_V6 }
nftables                  |		iif "lo" accept
nftables                  |		ether type 0x0806 accept
nftables                  |	}
nftables                  |}
nftables                  |table inet incus {
nftables                  |	chain pstrt.incusbr0 {
nftables                  |		type nat hook postrouting priority 100; policy accept;
nftables                  |		ip saddr 10.181.53.0/24 ip daddr != 10.181.53.0/24 masquerade
nftables                  |		ip6 saddr fd42:bd8f:f3c1:977a::/64 ip6 daddr != fd42:bd8f:f3c1:977a::/64 masquerade
nftables                  |	}
nftables                  |
nftables                  |	chain fwd.incusbr0 {
nftables                  |		type filter hook forward priority 0; policy accept;
nftables                  |		ip version 4 oifname "incusbr0" accept
nftables                  |		ip version 4 iifname "incusbr0" accept
nftables                  |		ip6 version 6 oifname "incusbr0" accept
nftables                  |		ip6 version 6 iifname "incusbr0" accept
nftables                  |	}
nftables                  |
nftables                  |	chain in.incusbr0 {
nftables                  |		type filter hook input priority 0; policy accept;
nftables                  |		iifname "incusbr0" tcp dport 53 accept
nftables                  |		iifname "incusbr0" udp dport 53 accept
nftables                  |		iifname "incusbr0" icmp type { 3, 11, 12 } accept
nftables                  |		iifname "incusbr0" udp dport 67 accept
nftables                  |		iifname "incusbr0" ip protocol 17 udp checksum set 0
nftables                  |		iifname "incusbr0" icmpv6 type { 1, 2, 3, 4, 133, 135, 136, 143 } accept
nftables                  |		iifname "incusbr0" udp dport 547 accept
nftables                  |	}
nftables                  |
nftables                  |	chain out.incusbr0 {
nftables                  |		type filter hook output priority 0; policy accept;
nftables                  |		oifname "incusbr0" tcp sport 53 accept
nftables                  |		oifname "incusbr0" udp sport 53 accept
nftables                  |		oifname "incusbr0" icmp type { 3, 11, 12 } accept
nftables                  |		oifname "incusbr0" udp sport 67 accept
nftables                  |		oifname "incusbr0" ip protocol 17 udp checksum set 0
nftables                  |		oifname "incusbr0" icmpv6 type { 1, 2, 3, 4, 128, 134, 135, 136, 143 } accept
nftables                  |		oifname "incusbr0" udp sport 547 accept
nftables                  |	}
nftables                  |}

So what gives? sshd is definitely running, and I don't see anything funny in the logs...

Post by Hu » Fri Mar 13, 2026 1:03 pm

Is sshd listening on that address:port pair? What does a packet capture of a failed connection attempt show?

leyvi · Post by **leyvi** » Fri Mar 13, 2026 2:45 pm

Hu wrote:Is sshd listening on that address:port pair? What does a packet capture of a failed connection attempt show?

I was able to confirm that indeed the sshd instance is listening on that port, on both IPv4 and IPv6 (at least according to my configuration file).

freke · Post by **freke** » Fri Mar 13, 2026 4:07 pm

You can confirm with

Code: Select all

ns ~ # netstat -lnp | grep -i sshd
tcp6       0      0 :::22                   :::*                    LISTEN      2075/sshd: /usr/sbi

And can also try stopping nftables to see if it works without the firewall to confirm that it is nftables that causes trouble.
If it's nftables that's causing problems, I'm out

never dived into iptables nor nftables.

leyvi · Post by **leyvi** » Tue Mar 17, 2026 3:58 pm

freke wrote:You can confirm with
Code: Select all
ns ~ # netstat -lnp | grep -i sshd
tcp6       0      0 :::22                   :::*                    LISTEN      2075/sshd: /usr/sbi
And can also try stopping nftables to see if it works without the firewall to confirm that it is nftables that causes trouble.
If it's nftables that's causing problems, I'm out never dived into iptables nor nftables.

Code: Select all

 $ sudo netstat -lnp | grep -i sshd
tcp        0      0 127.0.0.1:22            0.0.0.0:*               LISTEN      3210/sshd: /usr/sbi
tcp6       0      0 :::22                   :::*                    LISTEN      3210/sshd: /usr/sbi

I don't think that the issue is with nftables, since this used to work fine...

New at Gentoo · Post by **pietinger** » Tue Mar 17, 2026 4:05 pm

leyvi wrote:[...] I don't think that the issue is with nftables, since this used to work fine...

Yes ...

Code: Select all

# netstat -lnp | grep -i sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      10281/sshd: /usr/sb

Maybe check in your sshd config the line: ListenAddress 0.0.0.0

leyvi · Post by **leyvi** » Tue Mar 17, 2026 4:13 pm

pietinger wrote:
leyvi wrote:[...] I don't think that the issue is with nftables, since this used to work fine...
Yes ...
Code: Select all
# netstat -lnp | grep -i sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      10281/sshd: /usr/sb 
Maybe check in your sshd config the line: ListenAddress 0.0.0.0

From my configuration:

Code: Select all

 146 │ ListenAddress 127.0.0.1
 147 │ ListenAddress ::1

freke · Post by **freke** » Tue Mar 17, 2026 4:13 pm

leyvi wrote:
freke wrote:You can confirm with
Code: Select all
ns ~ # netstat -lnp | grep -i sshd
tcp6       0      0 :::22                   :::*                    LISTEN      2075/sshd: /usr/sbi
And can also try stopping nftables to see if it works without the firewall to confirm that it is nftables that causes trouble.
If it's nftables that's causing problems, I'm out never dived into iptables nor nftables.
Code: Select all
 $ sudo netstat -lnp | grep -i sshd
tcp        0      0 127.0.0.1:22            0.0.0.0:*               LISTEN      3210/sshd: /usr/sbi
tcp6       0      0 :::22                   :::*                    LISTEN      3210/sshd: /usr/sbi
I don't think that the issue is with nftables, since this used to work fine...

Isn't it only listening on localhost on IPv4 here?

freke · Post by **freke** » Tue Mar 17, 2026 4:27 pm

leyvi wrote:
pietinger wrote:
leyvi wrote:[...] I don't think that the issue is with nftables, since this used to work fine...
Yes ...
Code: Select all
# netstat -lnp | grep -i sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      10281/sshd: /usr/sb 
Maybe check in your sshd config the line: ListenAddress 0.0.0.0
From my configuration:
Code: Select all
 146 │ ListenAddress 127.0.0.1
 147 │ ListenAddress ::1

For IPv4 connectivity you should - as Pietinger suggested - set ListenAddress 0.0.0.0

ie. my mail-server allows both ipv4 and ipv6 sshd

Code: Select all

mail ~ # netstat -lnp | grep -i sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2581/sshd: /usr/sbi
tcp6       0      0 :::22                   :::*                    LISTEN      2581/sshd: /usr/sbi

ListenAddress 0.0.0.0
ListenAddress ::

my other servers only ipv6 ssh

Code: Select all

lamp ~ # netstat -lnp | grep -i sshd
tcp6       0      0 :::22                   :::*                    LISTEN      1791/sshd: /usr/sbi

ListenAddress ::