From ssh ec2 to TCP SYN: Tracing a Connection End-to-End

When an SSH connection to my EC2 instance timed out, I could’ve stopped at “fix the security group and move on.”
Instead, I decided to trace what actually happens when you run ssh ec2 — from the packet leaving my laptop,
through the Windows kernel and AWS firewalls, all the way to the SSH daemon on the server.
This post is a hands-on walk through the real software stack beneath the abstractions: TCP handshakes, cloud networking,
kernel drivers, and cryptographic key exchange — observed live on the wire.

The Original Problem

I ran:

ssh ec2

I got:

Connection timed out

But when I changed AWS Security Group from:

❌ Custom
to
✅ My IP

SSH started working.

Root cause (cloud side)

My EC2 Security Group firewall was blocking port 22 from your IP.

I got curious and I decided to understand what goes on under the hood.

Step 1 – Try to capture packets with Wireshark

I installed Wireshark and tried capturing traffic.

But:

❌ No packets were captured

This told us something important:
Wireshark GUI was running, but Windows kernel was not giving it packets.

Step 2 – Diagnose Npcap (kernel capture driver)

Wireshark relies on Npcap to hook into the network stack.

But when I executed this command on the power shell,

sc query npcap

Returned nothing.

Meaning:

The packet capture driver was not installed / bound correctly.

Step 3 – Discover Npcap was installed but not activated

I found:

Get-ChildItem "C:\Program Files\Npcap"

Npcap files existed, including:

npcap.sys
NPFInstall.exe

So the driver was present on disk — but not attached to my network interface.

Step 4 – Manually bind the kernel driver (real infra work)

cd "C:\Program Files\Npcap"
.\NPFInstall.exe -i2

Output:

Npcap Packet Driver (NPCAP) (WiFi version) has been successfully installed!

This did the critical thing:

✅ Attached Npcap to your Wi-Fi network adapter
✅ Inserted itself into the Windows networking pipeline

then:

.\NPFInstall.exe -r2

Then rebooted.

Step 5 – Verify kernel drivers are actually loaded

After reboot:

driverquery | findstr /i npcap

Output:

npcap        Npcap Packet Driver
npcap_wifi   Npcap Packet Driver

My OS is now capable of exposing raw packets to userland tools.

Step 6 – Launch Wireshark correctly

Start-Process "C:\Program Files\Wireshark\Wireshark.exe" -Verb RunAs

Step 7 – Observe the TCP handshake (what I originally wanted)

Now when I run:

ssh ec2

And filter in Wireshark:

tcp.port == 22

I can see:

68  4.469707    172.22.55.51    54.90.199.89    TCP 66  56959 → 22 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM
70  4.890446    54.90.199.89    172.22.55.51    TCP 66  22 → 56959 [SYN, ACK] Seq=0 Ack=1 Win=62727 Len=0 MSS=1318 SACK_PERM WS=128
71  4.890701    172.22.55.51    54.90.199.89    TCP 54  56959 → 22 [ACK] Seq=1 Ack=1 Win=65280 Len=0
72  4.909598    172.22.55.51    54.90.199.89    SSHv2   87  Client: Protocol (SSH-2.0-OpenSSH_for_Windows_9.5)
76  5.362436    54.90.199.89    172.22.55.51    SSHv2   75  Server: Protocol (SSH-2.0-OpenSSH_8.7)
77  5.362436    54.90.199.89    172.22.55.51    TCP 54  22 → 56959 [ACK] Seq=22 Ack=34 Win=62848 Len=0
78  5.385712    172.22.55.51    54.90.199.89    TCP 1372    56959 → 22 [ACK] Seq=34 Ack=22 Win=65280 Len=1318 [TCP PDU reassembled in 79]
79  5.385712    172.22.55.51    54.90.199.89    SSHv2   168 Client: Key Exchange Init
88  5.790794    54.90.199.89    172.22.55.51    SSHv2   990 Server: Key Exchange Init
90  5.799032    172.22.55.51    54.90.199.89    SSHv2   102 Client: Elliptic Curve Diffie-Hellman Key Exchange Init

I didn’t just learn “SSH uses TCP”.

I proved it with your own packets.

The Real Lessons

1️⃣ Cloud firewalls aren’t “abstract”

They literally drop packets on the wire.

2️⃣ Observability requires kernel hooks

You can’t “see networking” without drivers.

3️⃣ Infra debugging is layered

App (ssh)
↓
OS networking stack
↓
Kernel drivers
↓
Network interface
↓
Cloud firewall
↓
Remote kernel