Forum Discussion
Home Internet Static IP
Is it possible to get a static IP with the 5G Home Internet service? Normally I wouldn't need it but since my connection dies at least once a week I get a new IP every time my modem reboots. I work from home and whenever my IP changes I have to update some of my clients' firewalls.
- Daniel_BNewbie Caller
ArthurZey and others:
I'm in a dilemma. I activated Small Business Internet in store earlier this week and was given the Sagemcom gateway. The service is great, speeds are beyond expectations and I am ready to cancel Spectrum internet-- if it only wasn't for the ever-changing IP address. Thanks to your write-up I pretty much know how to go about it, except that no one seems to be able to get me the Inseego gateway. The store doesn't carry it and insists that I need to return my current gateway first before they can order the Inseego as a replacement. Business Care has no way of ordering it and neither does T-Force (all of them are sending me to the store). I am hesitant to do this only to end up with the paid service but no gateway. Plus there is some (mis?)information out there that the Small Business Internet cannot get the static IP, it needs to be switched to Business Internet by virtue of canceling and re-ordering the service. I am at a loss with so much bad and conflicting information from people who should actually know what they're talking about.
My questions to you are: how did you swap out your internet gateway? Did you also have to return the old one first? Second, can you confirm that you in fact have the Small Business Internet service and have static IP activated on it?
Many thanks!!
- iTinkeralotBandwidth Buff
If you want to set a local network device to have a static IP address the best course of action is to do so with an address outside of the DHCP scope but still within the IP network. T-Mobile supports 64 clients on the network and my observation based upon the gateway IP delivery via DHCP is that the pool of dynamic addresses runs from 101-254. The gateway IP is excluded so that leaves addresses 2-100 available. If any of these are used for static addressing on the network there should never be any conflict with any client which has received dynamic IP assignment from the gateway DHCP server. It is simple to confirm if a desired IP is available for sure. Open a console and ping the IP you want to use. If you get a response it is in use. If the ping responds as unreachable it is not in use. Just use addresses in the subnet not included as part of the DHCP pool.
- bocaboy2591Bandwidth Buddy
There is a simple workaround to the static IP problem. First, configure the device that you want to have a static address to DHCP and then plug it into your network with the T-Mobile gateway active. After the device is up and running, find the IP address it was assigned. You can do that with the T-Mobile Internet app, iNet, or any of the utilities available for this purpose. You will probably even be able to see the assigned address directly on the device in the settings menu or screen.
Nest, write down the IP address and then reconfigure the device for a static IP. Enter the IP address you just wrote down and restart the device. It will be at the assigned address and should stay there.
Note that this isn't always a permanent solution since the gateway can always reuse that address for another device on the network, but in my experience, this workaround will suffice in most cases, especially for always-on devices like printers.
It is unfortunate that DHCP can't be configured, at least on my Arcadyan KVD21 5G Gateway, but this kludge will at least help. I don't know what the Time To Live (TTL) setting for DHCP is on T-Mobile gateways, but my guess is it's long enough that the above solution will work.
- WarlocWearyTransmission Trainee
-
ArthurZey thank you ..
Thank you for the great write up. I was able to set up a business account. Worked with a really nice. Business account manager. Named Leo. He got me all set up. Overnighted the new router. Got me a static IP. Supposedly unlimited data. For $53 a month. And yes, they had to use a FX 2000.
I've had CenturyLink DSL for many years. It only got about 60 to 80. Downloads Depending on the time of day, I'm now getting 350. To 150. And now we have a static IP.I also am using the FX 2000. In bridge mode. And letting my router. Do most of the work. Amazing enough, I didn't even have to set the IP. Or anything in the router it just automatically assigned the new static IP. DNS etcetera.
I can access the web page of the modem. And my router. No problem. using : 192.168.0.1 for the router. and 192.168.1.1 for the modem everything seems to be working great.!
So now I have two modems. Lol. I'll have to send back the consumer grade one. That'll be a fun time.
-
- seekay3309Network Novice
It's been 2 years since I last tested the TM Home Internet 4G Gateway (speed was unreliable so I had to return it). 5G just became available in my area so I called them. I'm confirming as of this date 11/29/22, that Home Internet users do not have a public facing IP, and (after a transfer to their Business team) I'd need a Tax ID in order to get a Static IP. Ironically, this strict rule will be saving me from paying them another $600 per year.
I’ll stick with Spectrum for now as the dynamic IP I get from them is public facing.
- Hulu_UserNewbie Caller
This a joke. How can you call it home internet and have roaming IP addresses. @Tmobile and Hulu need to put your heads together and fix this. I had to have Hulu reset last night and now again today?
- IcarusNewbie Caller
ArthurZey wrote:
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.
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?
You are right. In pass-through mode, the router is MOSTLY bridging the WAN to the LAN as a layer-2 network switch. This allows your personal (non-T-Mobile) router to broadcast THROUGH the Inseego, to T-Mobile, a request for an automatic (static or otherwise) IP, and to get that IP.
But then, if your personal router has a public WAN IP (which is assigned a T-Mobile default gateway located in T-Mobile's network center to forward all packets to that are not destined for your home LAN... basically to "the cloud")... then you may wonder why the packets intended FOR your Inseego wouldn't slip through your Inseego, reaching T-Mobile's internet gateway, which in turn would drop the packets just because the destination IP is a private (non-internet-routable) IP?
Remember, I said it is... MOSTLY... a layer-2 switch? Well, it also doubles as a layer-3 IP device attached to (and listening on) that little switch. And it intercepts packets with its own IP as the destination, during passthrough. So even though the packet was being sent to the internet gateway in T-Mobile's building, the router breaks the rule and "opens someone else's mail". It would be like if you were writing a letter to a friend (who happens to work for the post office as a mail carrier) but you put the wrong house address. Normally, it wouldn't make it to the correct recipient, if you put the wrong address on the envelope, but this mail carrier checks every mail piece for his name, and if the name is his, he opens the mail and reads it, instead of delivering it to the house address written on the envelope. This is why he always gets his mail, by virtue of being the delivery middle man, no matter what address you write on the envelope. The Inseego in pass through mode has a rule, "transparently pass all packets between the WAN and LAN ports... UNLESS the destination IP happens to be my IP zof 192.168.1.1 (or whatever it's set to).. I'm going to steal those packets and pluck those out of the stream and not forward those through to the cell tower."
- IcarusNewbie Caller
ArthurZey wrote:
- If you have your own router, it might be tempting to set the Inseego FX2000 to “IP Passthrough” mode (under Settings → Advanced → LAN), so that your own router gets the public IP address (and you avoid being double-NATted), doing so will prevent you from being able to access the Inseego FX2000 configuration website (since it won’t have its own IP address to access via your browser), and you’ll lose access to some useful diagnostic information.
So I recommend against IP Passthrough, instead opting for putting your own router in the Inseego FX2000’s DMZ (under Settings → Advanced → Firewall), and to do so, you’ll probably want to configure your own router to use a static IP address on the Inseego FX200’s LAN subnet.
It is better to use IP Passthrough and then just add a new route for the Inseego's default IP (192.168.1.1) onto the WAN port of your router in your own router's route table. You add a route 192.168.1.0/24 (192.168.1.1 through 192.168.1.255) and attach it to the WAN port with a gateway of 192.168.1.1. When you type 192.168.1.1 in the browser, you can still access it through the connection.
- If you have your own router, it might be tempting to set the Inseego FX2000 to “IP Passthrough” mode (under Settings → Advanced → LAN), so that your own router gets the public IP address (and you avoid being double-NATted), doing so will prevent you from being able to access the Inseego FX2000 configuration website (since it won’t have its own IP address to access via your browser), and you’ll lose access to some useful diagnostic information.
- MykspersOBrienNewbie Caller
I've been on the phone with their "tech support" regarding this issue today and several times in the last few weeks regarding intermittent availability of service. I don't see how hard it would be to simply offer a public IPv4 address even if for a nominal fee.
I've been a T-Mobile customer since 2010. I haven't had much cause for complaint; as a cell carrier their service is relatively accommodating; as an Internet Service Provider, their architecture is frustrating.
- ArthurZeyRoaming Rookie
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.
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?
Contenido relacionado
- Hace 3 meses
- Hace 6 meses
- Hace 4 meses