Fixing VPN and VPC Connectivity Issues with T-Mobile Home Internet

I have been happy with T-Mobile Home Internet. I use it for remote work, and my family often streams a couple of TV shows, all concurrently, without any issues. About two weeks ago, in May 2025, I started encountering "server took too long to respond" errors when accessing cloud resources such as AWS OpenSearch. After researching online, it appears to be a common error for T-Mobile Home Internet users. Here is a step-by-step guide on how to restore your connectivity.

The Problem: T-Mobile Home Internet + VPN = Timeouts

Scenario: You can establish and maintain a VPN connection. But when accessing cloud resources, you get timeout errors in your browser. When you try to access the same resources over other ISPs, they work smoothly without any issues.

Connecting over a T-Mobile hotspot worked, maybe, once or twice, but no more than that.

Root Cause: From what I’m reading, T-Mobile Home Internet uses Carrier-Grade NAT (CGNAT), which adds packet overhead and can interfere with VPN traffic, especially when using standard MTU sizes.

Initial Symptoms and Diagnostics

What Works vs. What Doesn't

✅ Working:

• VPN connection establishes successfully
• Basic network connectivity through VPN
• Command-line tools like curl and openssl s_client can connect
• Resources accessible when using other ISPs

❌ Not Working:

• Browser requests to web applications result in timeout errors (in this case, with AWS OpenSearch over VPC)
• Specific error: "server took too long to respond"
• Interactive dashboards and web interfaces fail to load

Initial Diagnostic Commands

Before diving into solutions, establish what's working:

# Test SSL/TLS connection (this often works)

openssl s_client -connect your-resource.amazonaws.com:443

# Test HTTP connection (this usually hangs)

curl -I https://your-resource.amazonaws.com/path

At first, this stumped me. How can I connect to the port, but not get a response from a CURL HTTP request?

If openssl s_client works but curl hangs, it indicates an application-layer timeout issue, not a transport/network connectivity problem.

**If this is not your issue, or the solution below does not resolve your issue, some suggestions are:

• Review your ACL/IAM permissions
• Try different DNS servers

The Solution: MTU Optimization

Understanding the MTU Problem

Maximum Transmission Unit (MTU) determines the largest packet size that can be transmitted over a network, without fragmentation. I’m reading that T-Mobile's CGNAT infrastructure adds overhead to packets, causing fragmentation when using standard MTU sizes (1500 bytes).

The Fix: Reduce the MTU on your VPN tunnel interface to accommodate T-Mobile's packet overhead.

Step-by-Step MTU Fix

Step 1: Identify Your VPN Interface

After connecting to your VPN, find the tunnel interface. We will modify the VPN interface settings directly. This will allow us to connect these cloud resources over VPN, while maintaining the default, optimal setting for most other use cases.

Searching for tun\ is commonly used to find VPN tunnels:

# On macOS/Linux:

ifconfig | grep -A 2 tun

# Look for an interface with your VPN IP, example output:

# utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500

# inet 192.168.123.456 --> 192.168.654.987 netmask 0xfxff0f00

Step 2: Temporarily Set MTU

# Replace 'utun4' with your actual interface name

sudo ifconfig utun4 mtu 1200

# Verify the change:

ifconfig utun4 | grep mtu

Step 3: Test Immediately

# Test your connection right after changing MTU:

curl --connect-timeout 30 --max-time 60 -I https://your-resource.amazonaws.com/path

Step 4: Test in Browser

Open your browser and try accessing the resource that was previously timing out!

Step 5: Find Your Optimal MTU

I am reading that these different networks may require different MTU values, and that these are common values and the context in which to use them:

• 1200: Most conservative, works on nearly all networks
• 1300: Good balance of compatibility and performance
• 1380: Higher performance if it works on your network
• 1400: Maximum recommended for problematic networks

My connection has been working well with an MTU setting of 1300, and I will play around with increasing it for kicks.

You may notice that your ethernet or WiFi network adapters may not support an MTU value lower than 1280. But we can make these changes directly on your VPN interface, which will not impact other network connections.

Step 6: Remember to execute this command each time you connect to your VPN (after establishing the connection)

# Replace 'utun4' with your actual interface name

sudo ifconfig utun4 mtu 1200

Making MTU Changes Permanent

Some VPN clients may support configuring your MTU size. Look for an MTU or "Maximum Segment Size" setting in your VPN client's configuration.

My VPN provider did not easily support this, so I execute this command whenever I need to connect to the troublesome resources. This should last for the whole VPN session:

sudo ifconfig utun4 mtu 1300

But Why?

What Happens Without MTU Optimization

T-Mobile Home uses CGNAT, which creates multiple layers of network address translation.

Each layer adds packet overhead. The sum of PACKETSIZE + VPN + CGNAT makes the original packet larger than the MTU size (1500). The packets then need to be fragmented into more packets. Received packets must then be reassembled, and if necessary, sorted into the correct order. Now that more packets need to be generated, they are less likely to arrive in the correct order. And if they do not arrive within the TCP timeout window, the HTTP requests will fail.

If we set the MTU value optimally, the network interfaces do not have to send a large number of small packets, nor reassemble a large number of large packets. This also optimizes the CPU utilization.

With the original MTU value of 1500, latency may be increased:

• Packet fragmentation: +50-200ms
• Fragment reassembly: +20-100ms
• Retransmission delays: [phone]ms (timeouts)

Why does this affect VPN traffic more than others

Without visibility into the encrypted network traffic, T-Mobile can’t inspect and optimize the packets, and cannot execute traffic shaping.

Conclusion

I resolved my VPN connectivity issue with T-Mobile Home Internet, which is reportedly caused by packet fragmentation due to CGNAT overhead. Reducing the MTU on your VPN tunnel interface to 1200-1400 bytes worked for me.