Got something else to discuss that is not covered by the previous forums? Post it here!
#12282 by scottlindner
Mon Jun 29, 2009 4:39 am
kbern wrote:You wrote:
> You are testing the port forwarding from "outside", ie from a public IP address, as opposed to a computer that might be hanging off your ooma Hub or behind your router?

I don't think Ooma should behave that way because it means that it is changing the way my browser behaves/resolves vs. the way other people's do, it means some of my desktop links may not work when I'm at home (if, they point at my own server), and it makes it hard to test whether stuff really is accessible from outside.

The way routers and wireless access points/routers deal with port 80 issues like this is that if I want to get to the Ooma box's web UI page I would refer to it by its internal (downstream) name, e.g. 172.27.35.1. If I enter it's external (upstream) name (how the device before it sees it, in the case my cable modem) if it is not set up to forward a port, it should show its own UI, but if it *IS* set up to forward to port 80 on a downstream device, it should honor that request when it is called up via its "external" name.

This is how every router made works, and it really should be changed in Ooma.


That is not true. There are plenty of routers that will not display their configuration UI if port 80 is not forwarded. For one, as a default, that is a security risk.

My personal suggestion is if you have advanced networking needs you may want to consider Ooma's Advanced Networking Configuration. You'll get exactly what you want and Ooma won't need to compete against major router companies such as Cisco.

I have everything you are looking for in my network setup at home. I, and others on this forum, would be more than happy to walk you through how to do it.

As for the DNS loopback issue. This is a very common limitation in many residential routers. The last two routers I owned did not support DNS loopback.

Cheers,
Scott
#12285 by kbern
Mon Jun 29, 2009 6:49 am
> The problem is that if loop back isn't implemented, your computer uses DNS to get the external IP address and sends a request to that address.
1. Why would my computer use DNS when the IP is already an external IP?
> The router sends the request out into the void where it will be ignored
2. Why would the router be sending the request "out into the void where it will be ignored"? Why would it be "ignored"? I can enter that IP from another LAN (e.g. a friend's house) and it won't be ignored... because in this case it's the unique, external IP given by my cable company. Ooma is just trying to be "smart" about it and snatches it for itself because it notices, as they say in the horror movies, "the call (request) is coming from *inside* the house"
3. Whether some or all routers can handle this is irrelevant. *All* of mine (netgear and AirLink) do so the point is that Ooma *could* and *should* and I don't see a downside to them handling this properly.

- Keith
#12286 by scottlindner
Mon Jun 29, 2009 6:54 am
kbern wrote:1. Why would my computer use DNS when the IP is already an external IP?


Your computer uses DNS any time you enter a domain name (not an IP address). If you enter an IP address, your computer will not use DNS.


kbern wrote:2. Why would the router be sending the request "out into the void where it will be ignored"? Why would it be "ignored"? I can enter that IP from another LAN (e.g. a friend's house) and it won't be ignored... because in this case it's the unique, external IP given by my cable company. Ooma is just trying to be "smart" about it and snatches it for itself because it notices, as they say in the horror movies, "the call (request) is coming from *inside* the house"


Loopback requires very complex routing rules to support the way you are using it. The only people that require this capability are consumers, and very few consumers use this capability. There is little incentive or demand for this capability. Corporations handle this situation completely differently so it does not become a problem.

The request is not ignored, it is perceived as invalid. Again, due to complex routing rules that are not present.


kbern wrote:3. Whether some or all routers can handle this is irrelevant. *All* of mine (netgear and AirLink) do so the point is that Ooma *could* and *should* and I don't see a downside to them handling this properly.


I'm glad you have purchased routers that meet your needs. I have purchased routers that have not. Should Ooma compete against Cisco on router technology? That's a tall order for a tiny start up. I think you will find that everyone on this forum would prefer Ooma focus on telephony, not networking technologies. If you need help with advanced networking concepts and technologies we can help you achieve those goals, but asking Ooma to compete against Cisco is a tall order on short notice.

It sounds like you already have routers that satisfy your needs. Why not use those are your routers, and use Ooma as your telephone provider?

Scott
#12287 by kbern
Mon Jun 29, 2009 7:38 am
Ummm, I think you guys are missing the point here. This whole thread exists because of this issue. The first person who posted actually had everything set up right on his LAN but didn't know it because he couldn't test using the WAN IP. So, no, it's not just me, this would be a problem effecting *anyone* who wanted to do port forwarding to their intranet and be able to test it with the external IP.

And, no, I can't just use one of my routers because Ooma recommends that the Ooma device be the very first in the chain following the cable modem so that they can better direct traffic for call quality. This is *especially* why Ooma should take care of this.

I appreciate you trying to help, but telling me it's not a problem or being an Ooma apologist is simply no help. I'll be silent now until an actual Ooma rep replies.
#12289 by scottlindner
Mon Jun 29, 2009 7:58 am
kbern wrote:Ummm, I think you guys are missing the point here. This whole thread exists because of this issue. The first person who posted actually had everything set up right on his LAN but didn't know it because he couldn't test using the WAN IP. So, no, it's not just me, this would be a problem effecting *anyone* who wanted to do port forwarding to their intranet and be able to test it with the external IP.


I do port forwarding just fine, and can access my external sites from within my LAN just fine. I am willing to help resolve.

Scott
#12363 by kbern
Tue Jun 30, 2009 11:01 am
Thanks Scott. So, you're saying you have Ooma as the very first device after your cable/dsl modem, and then you have your webserver PC (or some number of routers and then the PC), and if you are on your *LAN* (e.g. in your house) and type your external IP+port (e.g. 92.247.54.16:80 (or whatever port you've chosen) that that request will show the HTML page served up by your internal web server (PC)? Because that doesn't work for me, and doesn't work for the person who started this thread, and is confirmed to not work by the Ooma guy who responded to the thread initiator.

Maybe you can access your internal servers via the DNS domain name, so maybe if I had dyndns set up this would work. Can you try your setup with the raw IP, as I've described above? Thanks. - Keith
#12376 by scottlindner
Tue Jun 30, 2009 1:29 pm
I just tested it and in a browser within my LAN I can hit my web server (not my router's configuration page) by entering just my Internet IP address.

However, a minor correction. I am using the Advanced Network Configuration that is recommended in the user's manual that came with my Ooma. I am not using the Basic Network Configuration. If you need advanced network features, you'll want to use the suggested Advanced Network Configuration as described in the Ooma User's Manual.

Cheers,
Scott
#12419 by kbern
Wed Jul 01, 2009 8:39 am
Thanks for the reply, Scott. That's right, that's what my post, above, supposed you did. That will work and I could do that too... it means having cablemodem->router->ooma as well as cablemodem->router->server (basically ooma and the server computer are peers hooked into the router. That *WILL* allow internal (LAN) traffic addressed to your external IP to go to your server without being snagged by ooma because ooma is not in the forwarding chain.

I could do that too, HOWEVER...

The reason I don't want to do that, as mentioned above, is that I want *all* my internal<->external traffic to go through ooma so that it can intelligently prioritize the traffic to give me the best call quality possible (this is discussed on page 28 of the Ooma manual in the section titled "Getting the Best Voice Quality"). I don't want my PC Server, for example, to suck up all the bandwidth, leaving Oooma with nothing.

So, my original suggestion to ooma still stands... if the ooma device gets a request initiated from "inside" using the *external ip*... it should let the request through. If it receives a request from inside using the Ooma LAN ip, it should show the Ooma UI.

Alternatively, at a minimum, if it gets a request for ports it doesn't deal with (pretty much all ports other than 80), such as 92.254.56.24:6547, it should pass those along. That would work for me too.
#12426 by scottlindner
Wed Jul 01, 2009 1:56 pm
kbern wrote:Thanks for the reply, Scott. That's right, that's what my post, above, supposed you did. That will work and I could do that too... it means having cablemodem->router->ooma as well as cablemodem->router->server (basically ooma and the server computer are peers hooked into the router. That *WILL* allow internal (LAN) traffic addressed to your external IP to go to your server without being snagged by ooma because ooma is not in the forwarding chain.

I could do that too, HOWEVER...

The reason I don't want to do that, as mentioned above, is that I want *all* my internal<->external traffic to go through ooma so that it can intelligently prioritize the traffic to give me the best call quality possible (this is discussed on page 28 of the Ooma manual in the section titled "Getting the Best Voice Quality"). I don't want my PC Server, for example, to suck up all the bandwidth, leaving Oooma with nothing.

So, my original suggestion to ooma still stands... if the ooma device gets a request initiated from "inside" using the *external ip*... it should let the request through. If it receives a request from inside using the Ooma LAN ip, it should show the Ooma UI.

Alternatively, at a minimum, if it gets a request for ports it doesn't deal with (pretty much all ports other than 80), such as 92.254.56.24:6547, it should pass those along. That would work for me too.


I recommend you call Ooma support directly.
#12763 by 00ma
Wed Jul 08, 2009 10:53 am
I have this same issue. Before OOMA was between the modem and my router, I could access mutiple websites I host using their DNS names. However, now I get the OOMA setup page when I type in one of my website address from within my LAN. From outside the LAN, everything is fine and works as before.

Any ideas how to get OOMA to not intercept whatever DNS urls are mapped to its WAN ip and just let it go through to the router which will forward to the webserver?

Who is online

Users browsing this forum: No registered users and 9 guests