Home Internet Static IP

DTV says it is a T mobile problem  and when I called T Mobile they claim it is a DTV problem, that they need to find a better way to track my location……

@scottyj: I basically concur with @Jrinehart76. Yes, it's definitely a DirecTV problem in terms of how they're attempting to "secure" legitimate access to their service. But T-Mobile isn't exactly making it easier, either. My static IP address from T-Mobile resolves to Bellevue, WA, which is about 1000 miles (and a whole timezone) off from where I am in Colorado.

Because of my need to access various network services at my home while I'm away, it's important that I have publicly accessible IPv4 addresses. (I don't actually care if they're static or dynamic, but I need durable port forwarding.) So with my Starlink connection, which, like the conventional T-Mobile 5G Home Internet, uses CGNAT and only a public IPv6 address, I need to make sure that individual connection is always VPNed. So I bought a static IPv4 address from my VPN provider so that I could get all the right ports forwarded, and I have a VPN router sitting between my multi-WAN router and my Starlink equipment. My static IP address from my VPN has GeoIP resolution closer to my actual home than my T-Mobile-assigned static IPv4 address.

My multi-WAN router establishes connections over whichever link (Startlink, T-Mobile, etc) is least saturated and has sufficient bandwidth. So sometimes, my video streams to these services go out over the VPNed Starlink connection. (The reason that all outbound connections--and not just inbound connections--need to go over the VPN IP address is related to how my Dynamic DNS client updates my public hostname with the IP address of whatever link is up.)

The irony for me is that Hulu, Disney+, and Netflix all block streams when they detect that I've happened to connect to them over the VPNed Starlink connection, all claiming that VPNs obscure my location and violate their terms of service. Reading their terms of service, that's not actually true, but more to the point, T-Mobile is more severely obscuring my location than my VPN is...not that any of this matters, since there are no content license differences between Colorado and any other state in the US. So I have to find my own workarounds to sus violation of their terms of service.

The obvious solution here would be to have their apps on my phone report their location based on GPS, which would give them accurate information to within a few meters at worst, rather than 1000 miles off. And they could even correlate the app on my phone with apps on TVs and such by looking at whether the devices are on the same network. And voilà--you know where your users are without worrying about whether VPNs are obscuring someone's location.

Ugh. Whatever.

@Jrinehart76:

to use IP Passthrough, first change the LAN settings of the Inseego to a subnet not found on your own router. I set my Inseego to 192.168.12.1/24 subnet (because I had the Nokia trashcan before) and my own equipment is on the 192.168.1.1/24 subnet. Once that was set, I then enabled IP Passthrough and I am still able to access the webGUI.

So yes, every segment is on a different subnet. My T-Mobile gateway is on 192.168.20.0/24, and my multi-WAN router is on 192.168.47.0/24. (And behind that, my Ubiquiti networking equipment is on 10.10.32.0/20.)

I have it on good authority from my colleagues who know more about network performance than I do that the fact of additional NATting is a drop in the bucket in terms of added latency compare to the mere fact of there being an additional device needing to forward/route packets at all. So I'm not that fussed about using IP Passthrough, since the DMZ solution works just fine.

That said, I’m curious about your recommendation, since I’m fuzzy on the technical details of network routing:

If I do IP Passthrough, it will assign my public T-Mobile IPv4 address to the WAN port of my ER605 multi-WAN router. So from the ER605's perspective, that port's IP address will be that public IPv4 address, not 192.168.20.10 (which I had configured statically to be on the Inseego FX2000's subnet).

What you’re saying suggests to me that the Inseego FX2000’s 192.168.20.0/24 subnet still somehow remains active, and that its 192.168.20.1 address remains accessible. Is that right?

In this configuration, I totally don’t get what the network configuration is of the Inseego FX2000 and which of its ports have what IP address attached to them.

I'm also confused about how, from a routing tables perspective, traffic to 192.168.20.1 would know to go out over the link whose IP address is 162.191.x.y (my T-Mobile-assigned IPv4 address). As I'm thinking about it, I wonder if that's a non-issue when there's only one path, but in my case, since I have 4 WAN links a connection could go over, maybe I have to create a static route on my ER605 that traffic destined to 192.168.20.0/24 needs to have its next hop be over the WAN port that the Inseego FX2000 is connected to.

Thoughts?