T-mobile 5G Home internet and VPN


Userlevel 2
Badge

I recently installed T-mobile 5G Home internet intending to replace Comcast Xfinity.  Installation was a breeze and I have the gateway/router setup at an ideal location in my home. I am getting download speeds on par with Comcast in my area (~200-230 Mbps) .  But once I logged into my work via VPN I noticed a significant downgrade in speeds.   I see downloads and uploads via VPN throttled way down (1-2 Mbps) compared  to without VPN.   I can confirm there are no bandwidth issues when the VPN is slow,  as I get very good speeds from a device that does not use VPN on the same setup.  

Also I still have my Comcast setup and when I switched my wifi to use the Comcast gateway I see speeds over VPN are more than 15X of what I see with T-mobile . So it looks like T-mobile is clearly throttling VPN traffic.  Everything else in the setup is the same (wifi,  target device, VPN network etc).  The only difference is the backend network (Comcast Vs T-mobile). I recall some mobile networks do this to prevent users from using their phones as a hotspot and log into work full time.  But this is unwarranted for a 5G home internet solution.


10 replies

Userlevel 2
Badge

Just finished talking to T-mobile tech support.  The tech support lady came up with a brilliant idea that this should be handled by the IT team at my work.  Her rationale was that Comcast is a fiber optic backend network and handles VPN differently than T-mobile 5G home internet which is all wireless. I tried to reason with her in vain that wireless alone is not the issue .  ( If I restart the TMO gateway and connect via VPN again the speeds are good for a minute or two before it gets throttled down,  so it's not the setup or the VPN network itself) .  Even the hotspot from my phone’s Verizon network does not throttle VPN this much (although it does) . 

T-mobile should advertise this as a strictly for entertainment home internet product. Anything else is misleading and a sureshot  class action material for fraud. 

Userlevel 5
Badge +7

Thanks for the update. As you note, I would expect download speeds to decrease with a VPN, but certainly not as much as you're stating. I use Mullvad VPN on my MacBook Pro, and I only see a ~10% decrease in speed.

I'd talk to your IT staff to see what they think. If they can’t figure it out, I’d have them call your VPN vendor and ask why this might be happening. T-Mobile would have no reason to prioritize normal Internet traffic over encrypted signals. To them it's just another request.

T-Mobile’s Home Internet protocol is called Fixed Wire Internet (FWI), same as Verizon’s, which is why you need a gateway as opposed to a cable modem to communicate. The back end of both networks is fiber, so in and of itself, this doesn't explain the slowdown.

Userlevel 2
Badge

I have contacted my work IT department and they have no clue about handling this other than providing me with local (geographic) VPN URLs which work ,  but they also have the same bandwidth issue over the t-mobile network.   At this point I am not going to spend further time and effort on this issue .  The onus is on T-Mobile to resolve this, which they seem to conveniently shrug off and point the blame somewhere else (every other network , i.e Comcast, Verizon etc work). I am just packing up the t-mobile gateway and returning it.  Will have to stick with Comcast even if they are a pain to deal with.  This whole ordeal was not worth it in the end.

I’m trying to find a solution as well, but mine doesn’t work at all. Change any of the variables and it works fine. Android phone with NordVPN enabled, connected to a TMobile tablet with cell hotspot enabled. That phone and NordVPN are fine on non-TMobile connections (ATT UVerse / XFinity / Verizon cellular). That TMobile tablet’s shared connection is fine with any device until you do NordVPN. I tried all three protocols in NordVPN.

I’m having this same issue via T-Mobile home internet and hotspot on a T-Mobile phone. 300-400 mbps without VPN. 10 mbps or less with VPN. Xfinity is approximately 80 mbps without, and 75 mbps with VPN. Hotspot through StraightTalk is similar. A little difference is understandable, but this is ridiculous. I got this service to be able to do my job, and now I can’t.

Any updates on this issue? I really want to stay with TMOBILE but their VPN issue is alienating a lot of WFH people, including me and my wife. We will sadly have to return the 5G Modem and go back to the competition.

I switched to tmobile home internet, and I have no trouble using my works VPN. This may not affect everyone in which sucks for people who are affected because it would reduce the urgency from tmobile on findingg a root cause.

 

My work place uses Cisco VPN in case that matters.

Appgate SDP Doesnt work.  

I adjusted the mtu with no difference seen.

PS C:\Windows\system32> netsh interface ipv4 show subinterfaces

MTU MediaSenseState Bytes In Bytes Out Interface

------ --------------- --------- --------- -------------

1412 1 0 392484 Loopback Pseudo-Interface 1

1431 2 0 5881 Appgate SDP

1384 1 377343768 245511532 Wi-Fi

1500 5 0 0 Bluetooth Network Connection

1412 5 0 0 Local Area Connection* 9

1412 5 0 0 Local Area Connection* 10

1500 5 0 0 Ethernet 4

1500 5 0 0 Ethernet 2

1500 5 0 0 Ethernet

1412 1 11152 1160080 VMware Network Adapter VMnet1

1412 5 0 0 Talk2m-eCatcher

1356 appears to be the largest packet before fragmentation.

PS C:\Windows\system32> ping thewindowsclub.com -f -l 1356

Pinging thewindowsclub.com [104.26.11.55] with 1356 bytes of data:

Reply from 104.26.11.55: bytes=1356 time=54ms TTL=49

Reply from 104.26.11.55: bytes=1356 time=40ms TTL=49

Reply from 104.26.11.55: bytes=1356 time=48ms TTL=49

Reply from 104.26.11.55: bytes=1356 time=63ms TTL=49

Ping statistics for 104.26.11.55:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 40ms, Maximum = 63ms, Average = 51ms

I set the adapters for 1356.

netsh interface ipv4 set subinterface "Appgate SDP" mtu=1356 store=persistent

netsh interface ipv4 set subinterface "Wi-Fi" mtu=1356 store=persistent

PS C:\Windows\system32> netsh interface ipv4 show subinterfaces

MTU MediaSenseState Bytes In Bytes Out Interface

------ --------------- --------- --------- -------------

1412 1 0 408828 Loopback Pseudo-Interface 1

1356 2 0 5881 Appgate SDP

1356 1 586759110 284827906 Wi-Fi

1500 5 0 0 Bluetooth Network Connection

1412 5 0 0 Local Area Connection* 9

1412 5 0 0 Local Area Connection* 10

1500 5 0 0 Ethernet 4

1500 5 0 0 Ethernet 2

1500 5 0 0 Ethernet

1412 1 11808 1204419 VMware Network Adapter VMnet1

1412 5 0 0 Talk2m-eCatcher

Did not work, I tried smaller MTU sizes, no difference.

I have been reading a lot of messages of T-Mobile home customers having similar VPN problems.

As next steps I am planning to try the following;

  1. I am planning to separate the router functions from the t-mobile modem using a dedicated router.
  2. Try a different modem that has settable options for beam forming, load balancing and Dual Sim (T-mobile and Google Fi)

Google Fi works with appgate SDP. I cannot use Google Fi exclusively at home because the data cap does not allow enough data for all my home devices for a month. I am hoping I sign up for T-mobile home before they enacted that data cap you talked about back in January.

I read a message from someone that sounded like they were an IT professional. I don’t know if they used a sniffer or something more sophisticated. That person claimed the data packets coming from T-mobile were malform. This person was specifically diagnosing appgate data packets.

I walked into T-Mobile store today and asked for the new white router (TMO-G4SE). They allowed me to exchange with the one that my VPN was not working on (FAST 5688W). My VPN is now working and (for now anyway) has averted the need to find another carrier.

Reading into this it seems like SPA is getting blocked. Can T-mobile please allow this?
 

•For TCP SPA - the packet sent to port 443 (tcp) must be allowed through.

•For UDP (and TCP) SPA packets are sent to port 53 (udp) and 443 (udp), one of which must be allowed through. If TLS is being used for the tunnel, the system will subsequently perform TCP SPA; so the packet sent to port 443 (tcp) must also be allowed through.


https://sdphelp.appgate.com/adminguide/v5.5/spa.html?anchor=spa

Reply