I have been operating a FreeBSD server "in the cloud" since December, 2024. A few days, or maybe a couple of weeks, before April 25, 2026, I began having trouble with frequent timeouts when connecting via ssh, dovecot, and radicale. (Radicale is a CalDAV calendar and contacts service which uses https on port 5232.) Other services seem to be unaffected; these are postfix (to receive incoming mail) and apache24. All of these services run on IPv6; in addition, smtp, http, and https are open on IPv4, and I have lately added ssh to the list of IPv4 services.
I would appreciate any help in understanding, diagnosing, and correcting the problem. For now, I'm focussing on ssh, in the hopes that curing whatever is ailing it will also cure the rest.
I've considered the following possibilities:
The server name is 'eagle'. The ssh client is a Linux Mint desktop computer, 'sparrow'
Eagle is currently running FreeBSD 15.0-RELEASE-p10, although the trouble started when it was running FreeBSD 14.3 (probably 14.3-RELEASE-p11, because the next thing I have in the log file is an update to 14.3-RELEASE-12).
Further observations:
1. When I have one ssh session from sparrow to eagle and am attempting another one which is not getting through, if I run `netstat -6` on eagle I typically see something like this:
If I understand correctly, SYN_RCVD means that the server has received a connection request (SYN packet) and sent back an acknowledgement (ACKSYN) but it's still waiting for the client to respond before the connection can be established. So, it looks to me like the client's response to ACKSYN is either not being sent, or is getting blocked or lost somehow.
2. The problem with ssh only occurs with IPv6, not IPv4.
3. Occasionally I get kernel log messages like this:
These occur infrequently (about twice per month in /var/log/debug.log, although five times in the most recent month of June, 2026) and since they are only on ports 80 and 443, presumably do not affect ssh or other services.
I would appreciate any help in understanding, diagnosing, and correcting the problem. For now, I'm focussing on ssh, in the hopes that curing whatever is ailing it will also cure the rest.
I've considered the following possibilities:
- Server's PF firewall does not let ssh connections in? Analysis of pflog files with tcpdump showed the firewall was blocking IPv4 connections to ssh, but not IPv6, and all of my attempts to connect were via IPv6. Besides, if the firewall were blocking ssh on IPv6, it would block it all the time, but in fact only about half of the attempted connections time out. Even after executing `service pf stop` the trouble persists.
- Network congestion, or denial of service attack? Live dump of pf with tcpdump indicates no excessive activity during the time while ssh waits for a connection. However, I'm not sure this is showing me everything. When ssh succeeds in connecting, there is no noticeable delay between a command such as `date` and the expected output; programs like `top` deliver outputs every 2 seconds as expected
- My ISP or the router in my home is suppressing packets that would complete the connection? The router is an ASUS RT-AX55 which was set up on March 28, 2025; I have made no configuration changes since January 20, 2026, but the trouble did not begin until a few months after that. The router does receive automatic upgrades of its firmware, though. The ISP is Spectrum, and I have no idea if they are suppressing anything.
The server name is 'eagle'. The ssh client is a Linux Mint desktop computer, 'sparrow'
Eagle is currently running FreeBSD 15.0-RELEASE-p10, although the trouble started when it was running FreeBSD 14.3 (probably 14.3-RELEASE-p11, because the next thing I have in the log file is an update to 14.3-RELEASE-12).
Further observations:
1. When I have one ssh session from sparrow to eagle and am attempting another one which is not getting through, if I run `netstat -6` on eagle I typically see something like this:
Code:
# netstat -6
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp6 0 0 eagle.ssh syn-2603-6010-c4.51392 SYN_RCVD
tcp6 0 0 eagle.ssh syn-2603-6010-c4.53782 ESTABLISHED
udp6 0 0 fe80::1%lo0.ntp *.*
udp6 0 0 localhost.ntp *.*
udp6 0 0 fe80::9400:3ff:f.ntp *.*
udp6 0 0 eagle.nt p *.*If I understand correctly, SYN_RCVD means that the server has received a connection request (SYN packet) and sent back an acknowledgement (ACKSYN) but it's still waiting for the client to respond before the connection can be established. So, it looks to me like the client's response to ACKSYN is either not being sent, or is getting blocked or lost somehow.
2. The problem with ssh only occurs with IPv6, not IPv4.
3. Occasionally I get kernel log messages like this:
Code:
kernel log messages:
+sonewconn: pcb 0xfffff8000dddaa80 (0.0.0.0:80 (proto 6)): Listen queue overflow: 193 already in queue awaiting acceptance (1 occurrences), euid 0, rgid 0, jail 0These occur infrequently (about twice per month in /var/log/debug.log, although five times in the most recent month of June, 2026) and since they are only on ports 80 and 443, presumably do not affect ssh or other services.