Firewall Issues - ssh_dispatch_run_fatal errors during SSH

Whilst this is true that Apple cannot fix the problem caused by others, however, this issue should not be ignored. MacOS 15.0.x borks TCP connections. See Little Snitch blog about Sequoia on TCP, Firewall issues https://obdev.at/blog/should-i-upgrade-to-macos-sequoia-now/

Disabling all third-party Network Filters will alleviate the issue temporarily (until, hopefully a fix on 15.1). macOS Firewall set to **block** all incoming connections (with the exception of some internal processes) works for me as well (you can set this to allow all and fine-tune the setting per third-party application).

As for VPN, well, I use Firefox connected to VPN via Windscribe and it works, so far so good. I have yet to run a VPN for all network connections, perhaps I will do this soon to test.

MacOS 15.0 is new, let's give Apple time to fix it -- also hoping that beta testers report this bug. As for us, let's continue filing bug reports, the more, the better, so Apple gets to prioritize it.

For the meantime, if you are from corporate IT, it is your responsibility to evaluate and certify new software before your users are allowed to download and install it. And if a user installs Sequoia, knowing that there is this bug AND if it is mission critical, then get them to revert back to macOS 14. :)

I was seeing this as well, the solution (for me) was that I noticed under network > VPN & Filters Lulu was present under Filters & Proxies even though I had not been using it for years (upgraded to little snitch). Once I removed it from the Filters & Proxies it has been stable ever since.

I spent 2 days debugging my Debian server until I realised this might be a problem on the client side. then I looked over the logs and

2024-09-22T07:53:26.484700+03:00 TheBrain sshd[285596]: Received disconnect from 192.168.0.180 port 56574:11: disconnected by user
2024-09-22T07:53:26.484948+03:00 TheBrain sshd[285596]: Disconnected from user user 192.168.0.180 port 56574
2024-09-22T07:53:26.485790+03:00 TheBrain sshd[285590]: pam_unix(sshd:session): session closed for user user
2024-09-22T07:53:26.491402+03:00 TheBrain systemd-logind[468]: Session 309 logged out. Waiting for processes to exit.
2024-09-22T07:53:26.493102+03:00 TheBrain systemd-logind[468]: Removed session 309.
2024-09-22T07:53:59.923525+03:00 TheBrain sshd[285605]: Connection closed by 192.168.0.180 port 56575
2024-09-22T07:53:59.923785+03:00 TheBrain sshd[285605]: Close session: user user from 192.168.0.180 port 56575 id 0 

so it's on the client side. And I solved this by disabling LuLu.

UPDATE:

Firewall is ON, Block Incoming is OFF, Stealth ON. Private WiFi is OFF. Limit IP Address Tracking is ON.

NEW: Network->Filter->Little Snitch DISABLED.

So far, so good. Connected to my RPi for 13 minutes (downloading a 1+GB file from the internet) and counting.

Hope this works for you guys.

Hi Mike,

After a dreadful morning with all sorts of weird connection problems, found your post here, and thanks to it I found out the culprit (at least for me).

If you happen to be using a content filter or proxy, disable it (at least temporarily). I was using Microsoft Defender and as soon as I turned it filter off in Network > Filters all issues gone. No need to turn off Firewall.

HTH.

UPDATE: My SSH connection seems stable with Firewall ON, Limit IP Address Tracking ON, Private WiFi OFF (need it for MAC address pairing for DHCP at home), but Little Snitch OFF (Network-Filters - all disabled). I also contacted Little Snitch creator and was told that the issue **might** be solved by 15.1 (not 15.0.1, unfortunately).

Hi everyone, I'm having the same problem too.

I'm using LAN connection (Home) and WiFI (Office) and the Issue having with both.

Today the SSH connection was constantly interrupted and after a few seconds or even minutes and I couldn't work.

I disabled the "Limit IP Address tracking" option and so far (barring surprises, and I'll keep you updated it seems to have disappeared) I haven't disabled firewalls and other programs.

I've been ssh'd for about an hour now and am having no problems. Let's hope so.

Guys, this is a very old and erratic bug in the Network Extension (I believe). Here are some references:

• Since Sonoma update, multiple times I get… - Apple Community
• https://forums.developer.apple.com/forums/thread/729348

The problem with this issue is that it comes and goes. It becomes more severe if you have a docking station with ethernet, VPN or a network filter (little snitch or lulu). Apple developers have been ignoring this issue deliberately for years. YEARS. The internet is FLOODED with people complaining about this (networking timeouts), but because this issue is not easily reproducible, and even worse, because this issue can at times only affect the speed of the connection (which can be blamed on other factors), no one hammered Apple to take it seriously. I know many people who abandoned Mac because of this.

If you want to know whether this issue is happening, while the internet/network is slow, just run a ping on your router. You'll get something like this:

$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 164 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=2306.502 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1300.413 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=295.091 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.242 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1830.929 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=2687.323 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1685.573 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=680.508 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=0.857 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=0.929 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=197.700 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=2764.140 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1762.121 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=756.605 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=0.983 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=2152.170 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1150.504 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=1859.144 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=854.277 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=0.943 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=0.790 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=0.545 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=1.522 ms
Request timeout for icmp_seq 2564 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=3073.333 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=3373.110 ms

Meaning, you'll get timeouts and unstable networking randomly. Notice how the time value goes up and down like crazy. This is why your internet is slow!

A restart might solve the problem temporarily. Another reason why many people just shrug it off.

I would've built the networking kernel module and debugged it myself, but this seems to be an issue with the Network Extension (since it's related to the OS firewall, filters, etc)... which is not open source! If it were open source, I swear I would happily build it in debug mode and fix it myself... this is how bad this is!

I think the only question that matters here is: How can we push Apple to do something about this? I'm happy to run a debug session with a developer to fix this... but they don't seem to want to take this seriously! Wtf do we do?!

[Edited by Moderator]

Disabling private rotating mac in the network settings solved the issue for me

Let us know if 15.1 "fixed" the issue for you.

For me, I no longer see " ssh_dispatch_run_fatal errors during SSH" errors. I have been SSH'd to my Linux server for the past hour and no ssh issues. Network packet drops is another issue all together, IMHO.

And as I have posted earlier - disabling Network Filters (Little Snitch), keeping the built-in firewall ON, Limit IP address to ON and Private WiFi to OFF worked for me prior to 15.1.

The issue in this thread is ssh_dispatch_run_fatal errors during SSH. 15.1 fixes that.

As far as I know the bug reported in this thread: ssh_dispatch_run_fatal errors during SSH, has been fixed. This same bug also seemed to affect RDP/3389. That also seems to be fixed. I've seen no reports of either behavior since 15.1 beta was out. The longest I went without getting kicked off of either after upgrading to 15.0 was something like 15 minutes, more frequently it would be within a minute or so with ssh and even more quickly with RDP.

I spend most of my working life in ssh and RDP and since the upgrade I've not been kicked off. There are other network bugs—my connections stall a few times an hour, but that looks to be due to some other issue.

I've been running 15.1 for three days and the SSH errors have completely gone away.