T-mobile 5G Home internet and VPN

Since this is for work, maybe a TMHI Business line would work.  I don't know if it would solve your VPN issue, but the TMHI business account is different, for example it allows a static IP.  The cost is more, however.

I would love to keep Tmobile, I work from home and I have to use VPN,

but performance is terrible for VPN, i guess they want to track all traffic so the can make $$ and discourage VPN use?

i like the price and performance of tmobile home service but I can’t compromise on the VPN speed.

has anyone solve this problem?

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

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.

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 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.

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'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.

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 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.