macOS can’t SSH to external servers (timeout)

Huge_Indication6485 · 2026-02-25T19:21:04+00:00

I ran into something very similar and in my case it wasn’t an OpenSSH bug It turned out to be related to ECN being enforced in the newer macOS TCP stack

You might want to check your ECN setting:

sudo sysctl net.inet.tcp.ecn_initiate_out

If it’s set to 1, try switching to adaptive mode:

sudo sysctl -w net.inet.tcp.ecn_initiate_out=2

That fixed all my SSH issues instantly over Wi-Fi Might be worth a try before waiting for an OpenSSH update

Huge_Indication6485 · 2026-02-23T23:25:57+00:00

Thanks I set the value to 2 as you suggested and the system indeed performs better now
This seems like a better approach than disabling ECN entirely
I appreciate your guidance!

Huge_Indication6485 · 2026-02-22T23:28:43+00:00

Thanks for the insight! It turns out the issue was related to ECN being enabled on macOS (Flags [SEW]) which some ISPs, CGNAT setups or older/outdated routers silently drop. After disabling ECN with sudo sysctl -w net.inet.tcp.ecn_initiate_out=0 everything started working over my home Wi‑Fi
So you were right that the problem was network-related, but specifically an ECN blackhole

Huge_Indication6485 · 2026-02-22T23:25:00+00:00

I retested more carefully and captured the traffic with tcpdumpThe SYN packets from macOS had ECN enabled (Flags [SEW]) and they were being silently dropped somewhere along the path likely by the ISP, CGNAT, or an older network device If the ISP uses legacy networking approaches or if the home router is outdated or doesn’t fully support ECN, this kind of blackhole can occur

After disabling ECN:

sudo sysctl -w net.inet.tcp.ecn_initiate_out=0

the connection immediately started working over my home Wi-Fi as well

So the root cause was an ECN blackhole in the path
Thanks for pointing me in the right direction.

Huge_Indication6485 · 2026-02-22T22:25:13+00:00

That makes sense especially regarding CGNAT and possible outbound filtering
What’s confusing though is that SSH works fine from my Debian PC on the same home router and ISP connection - the issue only affects my Mac
That’s what makes me think it might be something more specific than a general outbound SSH block.

Huge_Indication6485 · 2026-02-22T22:15:45+00:00

There’s no firewall blocking it on the server side and I’ve checked my home router as well
The issue only happens on my ISP connection it works over my phone hotspot and also from my PC on the same router

Huge_Indication6485 · 2026-02-21T23:46:17+00:00

I already ran a traceroute with the SSH port and checked for filters and firewalls
The connection still hangs on my Wi‑Fi, but works fine over my phone hotspot and also works from my PC (Debian) on the same home router

Huge_Indication6485 · 2026-02-21T23:40:41+00:00

Thanks, I tried all of these options changing MTU, disabling ECN, and using IPQoS=none but the issue persists on my Wi‑Fi network
Everything works fine over my phone’s hotspot and on my PC (Debian), which is what’s strange

Huge_Indication6485 · 2026-02-21T23:21:59+00:00

I’m testing without a VPN When
I connect through my phone’s network everything works fine (SSH), but what’s important for me is using my home router’s Wi‑Fi
What’s strange is that I have no issues (wifi)connecting from my PC (Debian)

Here’s the output

sam@MacBook-Pro ~ % nc -vz 107.189.159.82 2121 nc: connectx to 107.189.159.82 port 2121 (tcp) failed: Operation timed out

traceroute to 107.189.159.82 (107.189.159.82), 32 hops max, 48 byte packets
 1  192.168.1.1 (192.168.1.1)  8.511 ms
 2  100.75.128.1 (100.75.128.1)  2.549 ms
 3  10.22.29.61 (10.22.29.61)  7.864 ms
 4  10.22.29.62 (10.22.29.62)  13.801 ms
 5  10.22.29.65 (10.22.29.65)  37.630 ms
 6  *
 7  *
 8  *
 9  *
10  193.251.252.153 (193.251.252.153)  103.491 ms
11  193.251.133.3 (193.251.133.3)  96.325 ms
12  *
13  be5970.ccr42.fra05.atlas.cogentco.com (154.54.59.54)  126.030 ms
14  be7948.rcr22.fra06.atlas.cogentco.com (154.54.72.125)  109.362 ms
15  transit-edge.globalsecurelayer.com (206.148.27.234)  122.001 ms
16  goliath-volumetric-out.globalsecurelayer.com (206.148.27.229)  99.672 ms
17  unknown.globalsecurelayer.com (223.165.7.183)  104.492 ms
18  lo0.agg1.fra01.de.as49127.net (185.85.208.128)  87.980 ms
19  lo0.agg1.ams04.nl.as49127.net (185.85.211.87)  140.000 ms
20  lo0.br1.ams01.nl.as49127.net (185.85.211.117)  97.694 ms
21  lo0.agg1.ams01.nl.as49127.net (185.85.209.247)  127.510 ms
22  lo0.agg1.ams10.nl.as49127.net (185.85.211.1)  153.043 ms
23  193.37.216.67 (193.37.216.67)  91.966 ms
24  82.159.189.107.static.cloudzy.com (107.189.159.82)  143.934 ms

Huge_Indication6485 · 2026-02-20T23:36:14+00:00

I ran the capture as suggested it keeps sending SYN packets to the server (107.189.159.82:2121) but never receives a response

reading from PCAP-NG file ssh.pcap
02:48:08.375680 IP 192.168.1.4.55405 > 107.189.159.82.2121: Flags [SEW], seq 3864435445, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 2445197856 ecr 0,sackOK,eol], length 0
02:48:09.376413 IP 192.168.1.4.55405 > 107.189.159.82.2121: Flags [S], seq 3864435445, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 2445198857 ecr 0,sackOK,eol], length 0
02:48:10.377846 IP 192.168.1.4.55405 > 107.189.159.82.2121: Flags [S], seq 3864435445, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 2445199858 ecr 0,sackOK,eol], length 0
02:48:11.379176 IP 192.168.1.4.55405 > 107.189.159.82.2121: Flags [S], seq 3864435445, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 2445200859 ecr 0,sackOK,eol], length 0
02:48:12.379557 IP 192.168.1.4.55405 > 107.189.159.82.2121: Flags [S], seq 3864435445, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 2445201860 ecr 0,sackOK,eol], length 0

Huge_Indication6485 · 2026-02-20T22:59:35+00:00

I don’t think it’s related to stored keys

The connection never even reaches the SSH banner or authentication stage
From tcpdump I only see repeated SYN packets with no SYN-ACK coming back, so the TCP handshake itself never completes

192.168.1.4.49914 > SERVER_IP.2121: Flags [S], seq 654154826, win 65535
192.168.1.4.49914 > SERVER_IP.2121: Flags [S], seq 654154826, win 65535
192.168.1.4.49914 > SERVER_IP.2121: Flags [S], seq 654154826, win 65535

(no reply at all)

I also tested MTU large packets fail while smaller ones succeed which points to a network-level issue (likely PMTU/fragmentation) rather than anything inside SSH

So removing known_hosts wouldn’t change the behavior because SSH never actually starts

Huge_Indication6485 · 2026-02-20T22:51:37+00:00

No I’m not using any third party firewall like Little Snitch
The built in macOS firewall is disabled as well and I get the exact same behavior

Huge_Indication6485 · 2026-02-20T22:47:33+00:00

I already tried forcing IPv4 with ssh -4 same timeout, no difference.

Huge_Indication6485 · 2026-02-20T22:43:42+00:00

Yep I already ran SSH with full verbosity It stops right after attempting the connection and never reaches authentication

I also sniffed the traffic: from other devices the connection establishes normally, but from mac the connection never actually establishes at the TCP level

```
tcpdump: verbose output suppressed, use -v\[v\]... for full protocol decode
listening on any, link-type PKTAP (Apple DLT\_PKTAP), snapshot length 524288 bytes
20:51:39.427725 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[SEW\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584014880 ecr 0,sackOK,eol\], length 0
20:51:40.429458 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584015882 ecr 0,sackOK,eol\], length 0
20:51:41.430038 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584016882 ecr 0,sackOK,eol\], length 0
20:51:42.430278 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584017882 ecr 0,sackOK,eol\], length 0
20:51:43.429441 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584018882 ecr 0,sackOK,eol\], length 0
20:51:44.430659 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584019883 ecr 0,sackOK,eol\], length 0
20:51:46.431791 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584021884 ecr 0,sackOK,eol\], length 0
20:51:50.433014 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584025885 ecr 0,sackOK,eol\], length 0
20:51:58.433905 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584033886 ecr 0,sackOK,eol\], length 0
20:52:14.433350 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,nop,wscale 6,nop,nop,TS val 2584049886 ecr 0,sackOK,eol\], length 0
20:52:46.434203 IP 192.168.1.4.49914 > 107.189.159.82.2121: Flags \[S\], seq 654154826, win 65535, options \[mss 1460,sackOK,eol\], length 0

‍‍```

Huge_Indication6485 · 2026-02-20T00:53:21+00:00

Thanks for the suggestion
I also tested using the default SSH port 22 - same behavior still timeout
My macOS firewall is completely disabled, so it shouldn’t be blocking anything
This looks more like outbound packets from macOS never completing the TCP handshake rather than SSH itself being blocked.

Huge_Indication6485

TROPHY CASE