Upload speed slow

It would be good to know the cellular metrics for the 4G & 5G frequencies the gateway reports. If you have the Arcadyan or the Sagemcon you would need to use the T-Mobile HI mobile application to see those. I recently saw a couple of posts where users had stated the results using the Ethernet cable connection was worse than with wireless. Well, that I found strange but it was more than one user seeing the behavior. With the Nokia I have it is always better testing over the Ethernet cable connection. Results are more variable with the wireless link. 

Using speedtest.net is OK but another fellow user on the community brought to my attention that the test you can conduct at speed.cloudflare.com is pretty impressive. You really should both give it a spin. I think you might change your testing habits a bit. I now use speedtest, cloudflare, and fast.com. I like that I can set a preferred target server with speedtest.net but speed.cloudflare.com is slick.

With the company VPN testing you might go to your client’s adapter settings and reduce the maximum packet size to 1460 and give it a try. Keep in mind your client hits the CGNAT network on the way out. You might be getting some packet fragmentation due to the packet sizes being too large.

• GRE (IP Protocol 47) (RFC 2784) adds 24 bytes (20 byte IPv4 header, 4 byte GRE header)
• 6in4 encapsulation (IP Protocol 41, RFC 4213) adds 20 bytes
• 4in6 encapsulation (e.g. DS-Lite RFC 6333) adds 40 bytes
• Any time you add another outer IPv4 header adds 20 bytes
• IPsec encryption performed by the DMVPN adds 73 bytes for ESP-AES-256 and ESP-SHA-HMAC overhead (overhead depends on transport or tunnel mode and the encryption/authentication algorithm and HMAC)
• MPLS adds 4 bytes for each label in the stack
• IEEE 802.1Q tag adds 4 bytes (Q-in-Q would add 8 bytes)
• VXLAN adds 50 bytes
• OTV adds 42 bytes
• LISP adds 36 bytes for IPv4 and 56 bytes for IPv6 encapsulation
• NVGRE adds 42 bytes
• STT adds 54 bytes

NOTE: The packets may originate as a standard IPv4 packet with a designated MTU of 1500 bytes.

One thing you can do is take a packet capture with WireShark and investigate the session transfers. With the expert analysis option you can take a quick look and see if there are indications of errors or retransmissions or other issues when the traffic is running.

T-Mobile may be working on the tower in some locations. If the agent can tell you where the tower is and is actually getting their information about maintenance from a valid source then it may not be just another line to meet the call metrics. The agents are under pressure to meet metrics. Good or bad it is what it is. I don’t agree with the common practice for call handling but it has been a factor in customer service call centers for many years. I know I worked in customer support for 22 years. If you have an escalation engineer the equation may change but L1 engineers are evaluated by how efficient they are with handling calls. Hopefully looking at the traffic closer and adjusting the maximum MTU down to take into consideration the encapsulation will help. If 1460 helps but it still seems off go to 1400 and test again. You do have to duck as you enter the CGNAT and VPN tunnel if the packets are max size.