I Still Remember the Day SSH Refused to Work on Jio

Every once in a while, I remember an old incident from my early DevOps days and think:

“That was actually a really good troubleshooting exercise.”

This is one of those incidents.

It happened around four years ago.

I don’t remember every technical detail anymore, but I remember the problem, the investigation, the packet captures, the discussions, and most importantly, the feeling of finally figuring out what was happening.

The problem sounded simple:

SSH was not working.

But there was a catch.

It was working everywhere else.

Everything Worked. Except SSH.

The issue was happening only under a very specific combination:

Jio network + Pritunl VPN + SSH

If the client was using a different network, SSH was fine.

If we accessed other services, they were fine.

HTTP worked.

HTTPS worked.

The VPN itself worked.

But SSH was behaving strangely.

Something like:

HTTP       → ✅
HTTPS      → ✅
VPN        → ✅
SSH        → ❌

And that immediately made this a much more interesting problem.

If the server was completely unreachable, troubleshooting would have been straightforward.

But it wasn’t.

If the VPN was broken, we would expect other traffic to fail too.

But it wasn’t.

So we had a very specific question:

Why does SSH have a problem when the rest of the connectivity appears to be working?

This Was My Opportunity to Go Deeper Into Networking

At that point, I was leading the troubleshooting.

I knew this wasn’t going to be solved by simply checking SSH configuration and changing a few settings. The behavior was unusual, and I wanted to understand what was actually happening underneath.

Since Athira had strong networking knowledge, I brought her into the investigation. I knew her networking experience would be valuable, especially because we were starting to move beyond the application layer and into the network itself.

For me, this became a great opportunity to go much deeper into networking.

Instead of guessing, we decided to look at what was actually happening on the wire.

We weren’t going to start by randomly changing SSH settings.

We were going to watch the traffic.

Wireshark on One Side. tshark on the Other.

On my machine, we used Wireshark.

It gave us the nice graphical view of the connection.

We could follow the TCP stream, inspect individual packets, check sequence numbers, acknowledgements, timestamps, retransmissions, and much more.

On the server, we used tshark.

The server didn’t have a GUI environment where we could conveniently run Wireshark, so tshark gave us packet-level visibility directly from the command line.

The setup looked something like this:

Network Path

┌──────────────┐                                  ┌──────────────┐
│    Client    │                                  │    Server    │
│              │                                  │              │
│  Wireshark   │                                  │    tshark    │
└──────┬───────┘                                  └──────┬───────┘
       │                                                  │
       │              Jio Network                        │
       │                    ↓                             │
       │                Internet                         │
       │                    ↓                             │
       │              Pritunl VPN                        │
       │                    ↓                             │
       └───────────────────┴──────────────────────────────┘
                         SSH Traffic

The objective was simple:

See what is happening at both ends of the connection.

We Stopped Looking at SSH and Started Looking at Packets

This was probably the most interesting part of the whole incident.

Instead of:

“SSH isn’t connecting.”

we started asking:

“What is happening to the packets?”

We inspected the traffic in real time.

We looked at the packets leaving the server.

Then we looked at what was arriving at the client.

We compared timestamps.

We looked at TCP sequence numbers.

We checked acknowledgements.

We watched for retransmissions.

We followed the SSH connection as it progressed.

It felt less like debugging an application and more like watching two machines have a conversation.

Client                                  Server
  |                                       |
  | -------- TCP / SSH packet ----------> |
  |                                       |
  | <------- TCP / SSH response ----------|
  |                                       |
  | -------- ACK ------------------------>|
  |                                       |

Except sometimes, what the server said it had sent and what the client appeared to receive were not lining up the way we expected.

That was the clue we needed.

The Server Wasn’t Simply “Slow”

One of the important observations we made was around timing.

We could see the server transmitting traffic.

But the corresponding traffic wasn’t reaching the client at exactly the expected time.

That changed our thinking.

The question was no longer:

“Why is the SSH server taking so long to respond?”

It became:

“If the server sent the packet, what happened to it on the way to the client?”

That is a completely different troubleshooting problem.

Now we had to investigate the path:

Server
   ↓
VPN
   ↓
Internet
   ↓
Jio network
   ↓
Client

Somewhere in that path, something was behaving differently.

Why Did HTTP and HTTPS Still Work?

This was one of the things that made the issue confusing.

If there was a networking problem, why weren’t HTTP and HTTPS affected?

The answer isn’t necessarily that a network problem must affect every protocol equally.

TCP Traffic Can Behave Differently Depending On

• Packet size — how much data is carried in each TCP segment
• MSS (Maximum Segment Size) — the maximum TCP payload size negotiated between endpoints
• MTU (Maximum Transmission Unit) — the maximum packet size supported by a network interface/path
• TCP segmentation — how larger application data is split into multiple TCP segments
• Retransmissions — what happens when packets or acknowledgements are lost
• Path MTU Discovery (PMTUD) — how endpoints determine the largest packet size that can traverse the path without fragmentation
• VPN encapsulation — additional headers introduced by VPN protocols, reducing the effective payload size
• Network-path characteristics — routing, packet loss, latency, filtering, and behavior of intermediate networks

So it is entirely possible to have a situation where:

Small / different traffic pattern
        ↓
       Works

Different packet behavior
        ↓
       Problem

That’s why “HTTPS works” isn’t enough to conclude that the network path is healthy for every kind of traffic.

Then We Looked at the VPN

The next important piece was Pritunl.

The client wasn’t communicating with the server over a simple direct connection.

There was a VPN tunnel in between.

Get Midhun Krishna’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Conceptually:

Client
  |
  | Jio
  |
  v
Internet
  |
  v
Pritunl
  |
  | VPN tunnel
  |
  v
Server

And VPN tunnels introduce additional packet overhead.

A normal packet might look conceptually like:

+-------------------------------+
| IP | TCP | Application Data   |
+-------------------------------+

After VPN encapsulation, it becomes something more like:

+------------------------------------------------+
| Outer IP | VPN | Inner IP | TCP | Application |
+------------------------------------------------+

That extra encapsulation matters.

Because now the packet has to fit through the MTU available on the underlying network path.

And that brought us to one of the oldest networking concepts:

MTU.

The MTU Rabbit Hole

MTU stands for Maximum Transmission Unit.

In simple terms, it represents the maximum size of an IP packet that can be transmitted over a particular link without fragmentation.

A common Ethernet MTU is:

1500 bytes

But when traffic passes through VPN tunnels, additional headers consume part of that space.

So the effective packet size available to the original traffic can be smaller.

Conceptually:

Normal network

[------------- 1500 bytes -------------]

VPN
[Outer][VPN][----------- Inner packet -----------]
       ↑
       Additional overhead

And if the network path has an even smaller effective MTU, things can become complicated.

Packets may need to be fragmented, dropped, retransmitted, or otherwise handled differently depending on how Path MTU Discovery and the intermediate network behave.

We weren’t initially looking at MTU.

The packet observations gradually pushed us in that direction.

Then Came the Experiment

Eventually, the observations from our packet investigation were passed to Vibin. He Took the Investigation Further

At this point, I had shared the packet-level observations and everything we had found so far with him.

He continued digging into the network behavior and suggested that we test different MTU values.

That turned out to be an important direction.

We started with the default:

MTU 1500

The problem was still there.

Then we reduced it:

MTU 1250

And suddenly, SSH worked.

We tested another value:

MTU 1200

SSH worked there as well.

So the results were pretty clear:

1500  → ❌ SSH problem
1250  → ✅ SSH working
1200  → ✅ SSH working

At that point, we had a very strong practical clue.

Reducing the MTU resolved the issue.

We didn’t have to guess anymore. We had changed one specific network parameter, reproduced the problem, changed it, and watched the behavior change.

For me, this was one of the most interesting parts of the whole investigation. What initially looked like an SSH problem had taken us all the way down to packet captures, VPN behavior, network paths, and MTU.

I Wish I Had Saved the Packet Capture

This is the part where I need to add a disclaimer to my own memory.

This happened roughly four years ago.

I don’t have the original Wireshark capture or the complete RCA sitting in front of me today.

So I don’t want to claim that I remember the exact packet, exact SSH message, or exact reason for every delay.

I remember the observations.

I remember the troubleshooting.

I remember comparing the client-side Wireshark capture with the server-side tshark output.

And I remember that reducing the MTU to 1250 or 1200 resolved the problem.

The exact packet-level explanation is something I would want to verify from the original capture before claiming it as fact.

And honestly, that’s an important lesson too:

Don’t turn an old memory into a confident RCA.

What Made This Incident Special

Looking back, the actual fix wasn’t the only interesting part.

The investigation itself was the valuable experience.

It gave me an opportunity to explore areas of networking that I didn’t get to work with every day.

I learned to look at:

Application
    ↓
SSH
    ↓
TCP
    ↓
IP
    ↓
VPN
    ↓
Network Path

Instead of stopping at the application layer.

And I got to work alongside people with different strengths.

Athira helped throughout the networking investigation and brought strong networking knowledge.

I led the troubleshooting and drove the packet-level investigation.

Then Vibin took our observations further and connected them to the MTU change that ultimately resolved the problem.

That’s how real troubleshooting often works.

Not:

One person knows everything.

But:

One person observes something.
Another person notices a pattern.
Someone else tests a hypothesis.
And eventually, the pieces fit together.

Four Years Later, This Is What I Remember

I don’t remember every packet.

I don’t remember every timestamp.

I don’t remember exactly which Wireshark filter we used.

But I remember sitting there and watching packets move between two machines.

I remember switching between Wireshark on the client and tshark on the server.

I remember trying to understand why a packet sent from one side wasn’t showing up on the other side when we expected it.

And I remember the moment when changing the MTU made the problem disappear.

That experience gave me something much more valuable than just fixing one SSH issue.

It taught me to go lower in the stack when the behavior doesn’t make sense.

Sometimes, You Just Have to Follow the Packet

When an application says:

“Connection failed.”

that’s only the beginning of the investigation.

There could be something wrong with:

Application
      ↓
Transport
      ↓
Network
      ↓
VPN
      ↓
Routing
      ↓
MTU
      ↓
Physical network

The application only knows that something went wrong.

The packets can tell you where to start looking.

And that’s probably why I still remember this incident after four years.

It wasn’t just an SSH problem.

It was one of those rare troubleshooting opportunities where you get to step back, open Wireshark, inspect the traffic, compare both ends, and slowly work your way toward the answer.

Sometimes the most interesting debugging sessions begin with a very simple question:

Why the hell does SSH work everywhere except on this one network?

And sometimes, the answer is hiding somewhere between two packets….