Forum Discussion
RBK50 Port Forwarding Help
So you guys won't believe this -- I decided to change the range of the DHCP-assigned LAN IP addresses from [192.168.1.2 to 192.168.1.254] to [192.168.1.2 to 192.168.1.100].
In my previous address reservation attempts, I set the reserved IP to 192.168.1.25 ...26, 27, etc. Then I set it to something really far out within the IP range, namely 192.168.1.100. Still within the original range, and still within the new range.
So technically nothing should change, right? But wait, there's more! When I changed the range, clearly the router did "something" and reset all connections. I noticed that even my router page was no longer accessible (for the time being). So when I simply typed "ipconfig" (without releasing or renewing anything) into my PC, it showed 192.168.1.100!
It's almost as if changing the DHCP-assigned IP range caused the system to start from scratch (perhaps the DHCP table itself got rebuilt) and therefore assigned my PC the correct reserved IP address of 192.168.1.100.
The question now is -- if I change the address reservation to another IP or if I reserve another IP for another device, will it work? Or will I have to "reset" the DHCP by changing the IP range again... I'm scared to try.. haha..
I know this is an old thread but I was having the same problem with reserved addresses not getting assigned. I tried the "trick" of changing the DHCP addresses from x.x.x.21 to x.x.x.254 TO x.x.x.21 to x.x.x.100.
Restarted the devices that were not getting the addresses I wanted and it all worked. I had tried restarting the devices prior to changing the auto assigned addresses range and it did not work at that time. Only after changing the range of the auto addresses.
I know enough to know that should not change the addresses I wanted reserved. Nothing was assigned in the >100 range in the first place. All I know is it solved my problem.
Well, fudge. Your public IP is well-known, yet when you try to connect to it, the packets never arrive.
Another thing to try: On the Advanced Tab, Advanced Settings, Remote Management. Turn on Remote Management, then try to connect to https://<public IP>:8443.
The web browser will complain about the SSL certificate being expired (or "not secure"), but you should be able to log into the Orbi web interface.
I do not leave the Remote Management function on because my Orbi log gets cluttered with bad login attempts. As soon as the scum on the internet detect that port 8443 is open, they immediately try to log in. With a 25 character password, they have "no change", but it generates too many log entries, so I'd rather leave it off. I use OpenVPN for remote management.
Tried with the IP that google says my IP is: no luck.
Tried with the IP Orbi says my IP is (on my own network): worked, with the SSL error
Tried with the IP Orbi says my IP is (on my phone, on LTE): did not work, no luck.
Tried with the IP Orbi says my IP is (on my phone, on WiFi): resolved to the system, but Safari did not let me continue past the SSL error
- Please report what the ISP says. Looks like no way the IP is connecting to the Orbi.
Got a response:
"Thank you for contacting [us]. You may want to consider purchasing a static IP if you are working with trying to have the same IP for access. The way our network works the public IP would differ due to the way our network is configured. It would cost 10 dollars a month in order to have a static IP. Please contact us via phone at [phone number] if you do wish to purchase a static IP."
Not much to go on, but it sounds like they configured their network a certain way to do this?
This is not an answer. They did not read the question. Virtually everyone has a "dynamic IP". (I certainly do.) This is the reason "Dynamic DNS" services exist. If you check "What is my IP Address?" several hours apart, or even several days apart, I bet it will be exactly the same. Mine has been the same for months.
Orbi has built in support for No-IP.com and Dyn.com (I use No-IP.com. Have no specific reason I picked it.) Orbi periodically checks its public IP address and updates the DDNS service, "I am here now." So, instead of my OpenVPN Client connecting to <my-ip>, it connects to <my-Orbi-name>.mynetgear.com
Yes, every ISP sells static IP addresses for $$/month, and businesses purchase them. In the business world, having a dynamic IP address causes problems when clients cache the IP rather than the name. (Lose business!) For residential customers, a DDNS service takes care of IP address changes.
You got a "canned response" from someone who did not read the question. Hope you can get someone on the phone.
(Sorry about the rant. My cat wanted up early this morning.)
Yeah, I figured as much. I know the purpose of DDNS as well, as once this port forwarding issue is fixed I plan to use Duck DNS for that exact purpose.
I also just received a response back: "Our network is configured and runs on a dual NAT setup. This is why the IPs differ. You have an IP in our network, then a separate IP for the internet off of our IP as a result."
Also, sorry for your cat, mine hits my head when I don't wake up to feed him.
- Then you are screwed.
Ah, I figured! I'm going to email and ask if the static IP would give me a static-public facing IP or a static-inner facing IP. If it's forward-facing, might be coughing up $10 a month for it. Thanks for all of your debugging help! Sorry the solution wasn't that exciting...
I would be very surprised if it is not "public facing". That is the entire point of a static IP.
On a side note, I can understand their situation. Back when the internet was created, there were at most a few thousand computer systems to connect. Blocks of IP addresses where handed out almost on a whim. My university got a "Class B" address space, 137.151 if I remember correctly, which is enough to provide over 65,000 IP addresses. At that point, we had only a couple of thousand devices on the whole campus. Coming in "late to the game", a new ISP may be lucky to get a Class C address space of 254 addresses to support all of their customers.
IPv6 was created to deal with this original failure to anticipate how ubiquitous computer devices would become, but Network Address Translation (NAT) has enabled the world to go merrily along ignoring IPv6.
