Several months ago I got T-Mobile Home Internet service (using their “trashcan” router). I was using it as a backup service to my primary connect (Cox cable) and set up a Speedfusion Cloud connection to SFC-LAX. Cox is connected to WAN 1 and T-Mobile is connected to WAN 2.
When I originally set things up, the Speedfusion Cloud connection was working fine. I could pull the plug on Cox (WAN 1) and I didn’t notice a thing (and vice-versa with WAN 2).
However, today the Cox connection failed and the Speedfusion tunnel went down because it could not connect via T-Mobile.
I know that T-Mobile uses CGNAT, which can be a problem, but everything was working flawlessly a few months ago. I have a PepVPN connection that is outbound over the T-Mobile connection and it still works fine.
I’m using a Balance 20 router (HW 7) with the latest firmware (8.1.3 build 5021).
Notice that they are both trying to connect to the same destination: 192.168.12.231:4500
The T-Mobile router assigns NAT addresses in the 192.168.12.0/24 range (this is not adjustable). It appears that it is mapping the external endpoint address (or port 4500) to an internal NAT address. Unfortunately, the T-Mobile router does not have very many settings that can be changed by the user.
Can you disable the CR_HOUSE tunnel, and see if the SFC works as the only tunnel.
Can you try moving the port# of CR_HOUSE to 4501 (you only have to do this on the current peplink)
take pictures with the “show remote connections” highlighted.
Can you switch the protocol from UDP to TCP?.. it is an experimental under “data port” Click on the “?” and then select TCP. the NAT processing code might prefer that.
What is key “where is the traffic getting dropped”. it might be a limitation of the t-mobile router that it can’t handle multiple UDP NAT’s with the same port via the CGNAT. Also port 4500 is used for NAT-T IPSEC traffic, so that can be mapped to special NAT handling rules. Testing with a FusionHub would allow you to capture packets and give more debugging information than a SFC endpoint.
I had a problem yesterday where none of my VZW SF tunnels that used port 4501 would work… but 4502 was fine. No problem with my AT&T systems. I just moved the client side to port 4503 and they worked again. Why?.. I don’t know, just that the return packets didn’t get all of the way from my FusionHub back to the remote.
I tried disabling the CR_HOUSE tunnel, but SFC-LAX connection on T-Mobile WAN 2 still does not work. Also tried changing to UDP and it made no difference.
I tried switching to port 4501 on the CR_HOUSE tunnel, but the status shows that it is still connecting to port 4500.
T-Mobile recently updated the firmware on their router, so that may be related to the problem. Everything used to work fine and I have not changed anything on my Peplink router. It’s still running the same firmware. I would try calling T-Mobile support, but their front-line people don’t know anything and it’s impossible to get thru to a network engineer who can understand the problem.
When I have time, I’ll try to reactivate my FusionHub and test a few more things.
I’ve got to get some real work done right now and not waste hours playing with various network parameters. Will get back to this problem later.
Before I signed up for this service, T-Mobile told me that they could provide a public IPv6 address. Guess I shouldn’t believe everything that a salesperson tells you.
Unfortunately, no. The unavailability of a real public IP address is a major complaint from many T-Mobile Home Internet users.
I enabled IPv6 on WAN 2, but DHCP from the T-Mobile router still assigns 192.168.12.231 to it.
However, I noticed that an IPv6 address: 2607:fb90:729b:1114:e8e2:f82b:0:8e0 is now associated with the LAN interface. When I did a lookup, this address belongs to T-Mobile, but I’m not sure what good it does me.
I have a SpeedFusion connection going through the old Askey version of that router with T-Mobile home internet. I’ve had that happen from time to time, but a reboot has always fixed. The only time it stays broken is when I turned off the ALG for IP-Sec on this screen…