Why I Couldn’t SSH Into My OCI VM Using Mobile Hotspot (And How I Finally Fixed It)

There are moments in cloud troubleshooting where everything looks perfectly configured… and yet, nothing works. This was one of those moments.

I had set up an Oracle Cloud (OCI) virtual machine, configured the networking correctly, added my public IP to the security list, and confidently tried to SSH into the server.

And then… it failed. Not once. Not twice. Every single time.

If you’ve ever faced a similar issue while working on a mobile hotspot, this article will save you hours of confusion.

🔍 The Setup — Everything Looked Correct

Let me first explain the setup so you can relate.

I had:

A compute instance in OCI with a public IP

A security rule allowing SSH (port 22) from my IP

My laptop connected via a mobile hotspot

From a configuration standpoint, this is textbook correct. In a typical home or office broadband setup, this should work instantly.

But here’s the catch — mobile networks behave very differently.

🧪 The First Suspicion — IP Mismatch

When SSH didn’t work, I did what most of us do — I verified my IP address. From the browser, I checked using an IP lookup website.

Then from terminal, I ran: curl ifconfig.me

To my surprise, both showed different results. At first glance, this might look like a minor inconsistency. But in reality, this is the starting point of the entire problem.

⚠️ Understanding the Real Problem

After digging deeper, I discovered that two things were happening simultaneously — and both are very common when using mobile hotspots.

🌐 1. IPv6 vs IPv4 Mismatch

The IP returned from the terminal looked something like:

2509:50c2:104d:df9b:9e6b:732d:a081:d7e2

This is clearly an IPv6 address. However, most OCI environments (unless explicitly configured) operate using IPv4:

Public IP assigned to VM → IPv4

Security rules → IPv4 CIDR ranges

SSH access → typically IPv4

So what was happening?

👉 My laptop was trying to connect using IPv6

👉 My OCI VM was expecting IPv4 traffic

These two simply don’t talk to each other unless specifically configured.

📡 2. Carrier-Grade NAT (CGNAT)

Now comes the second and more subtle issue.

Mobile network providers don’t assign a unique public IPv4 address to every user. Instead, they use something called Carrier-Grade NAT (CGNAT).

Let me simplify this.

Instead of:

Your Laptop → Internet → OCI VM

The actual flow looks like:

Your Laptop → Mobile Network NAT → Shared Public IP → OCI VM

This means:

• Your device does not directly own a public IPv4 address
• Multiple users share the same external IP
• The IP you see may not be the one OCI sees
• The IP can change frequently

So even if you whitelist an IP in OCI, the request might come from a completely different IP.

🚫 Why SSH Failed Despite Correct Configuration

At this point, everything started to make sense.

I had configured:

Source: <my-ip>/32

Port: 22

But OCI evaluates the actual incoming IP, not what I think my IP is. Due to CGNAT and IPv6 behavior:

My outgoing request did not match the whitelisted IP. OCI security rules blocked the connection.

Result → SSH timeout

This is why the issue feels so confusing — because the configuration is technically correct, but the network behavior breaks the assumption.

🧪 Confirming the Diagnosis

To validate this, I ran:

curl ifconfig.me

curl -4 ifconfig.me

curl -6 ifconfig.me

At this point, it was clear that this was not an OCI issue — it was a network limitation.

✅ What Actually Works (Practical Solutions)

Once you understand the root cause, the solution becomes much clearer.

🥇 Solution 1 — Use OCI Bastion (Recommended Approach)

The most effective and professional way to handle this is by using

OCI Bastion

Instead of exposing your VM directly to the internet, Bastion acts as a secure entry point.

Why this works so well:

• It does not rely on your public IP being stable
• It works even if your IP changes frequently
• It eliminates the need to open SSH to the world
• It aligns with security best practices

In simple terms, you connect to Bastion, and Bastion connects to your VM internally. This completely avoids the problems caused by CGNAT and IP mismatch.

🥈 Solution 2 — Forcing IPv4 (Temporary Workaround)

If you still want to try direct SSH, you can attempt to force IPv4:

curl -4 ifconfig.me

If you get a valid IPv4 address:

Add that IP in OCI security rules

Use ssh -4 to force IPv4 connection

However, this is not reliable because:

• The IP may change at any time
• CGNAT may still interfere
• You may lose access intermittently

This is more of a quick test rather than a long-term solution.

Conclusion

This issue wasn’t really about OCI configuration — it was about how mobile networks behave. With CGNAT, dynamic IPs, and IPv6 in play, the IP you whitelist is often not the one OCI actually sees, which leads to SSH failures.

Instead of trying to chase changing IPs, the better approach is to use solutions designed for such environments, like OCI Bastion or OCI Cloud Shell.

👉 The key takeaway: when working from a mobile hotspot, don’t rely on IP-based access — use network-independent access methods for a stable and secure connection.

Thanks & Regards,

Chandan Tanwani