Forum Discussion
T-mobile 5G Home internet and VPN
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.
- drmalcolmRoaming Rookie
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.
- drmalcolmRoaming Rookie
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.
- ScooberDiverNewbie Caller
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.
- bocaboy2591Bandwidth Buddy
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.
- uneekuzerNewbie Caller
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.
- VPNblockedNetwork Novice
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.
- dvklNetwork Novice
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.
- VPNNetwork Novice
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;
- I am planning to separate the router functions from the t-mobile modem using a dedicated router.
- 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.
- Dad602Network Novice
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.
- lfgf044Network Novice
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
Contenido relacionado
- Hace 3 meses
- Hace 4 meses
- Hace 2 años