I run a couple servers inside my network, mostly relying on a reverse-proxy to accept connections on TCP 443 and proxy the connections to the right internal server. I don't run separate internal v. external DNS. Instead, I have a more typical setup where I define an external DNS server in eero, then the eero includes its address as the DNS server in all DHCP addresses, and forwards the requests.
As a result, though, I can't access my server by [subdomain].[domain].com while *inside* my eero network. I have to instead use DNS shortnames. This is annoying for a number of reasons.
Google WiFi DOES support it. As does Luma and AmpliFi.
I've stuck with my Linksys EA9500.
russwittmann idiot google support. I asked him specifically about NAT loopback and they said they don't have that feature supported. I did like google wifi. But the only thing I didn't like about it is that it doesn't support Class A DHCP.
Do you recommend Google wifi over Eero? I might go back to Google WiFi if it supports the loopback (I tried Google WiFi for half a day). It's hard to code websites running at a home server if eero doesn't support loopback.
crispywisp I'm in your same boat and everything works fine for me with Google WiFI. I will say chances of Class A DHCP Support in Google Wifi will probably come faster than nat loopback on eero. In my opinion eero is really a basic out of the box consumer product and not ready for advanced users.
I just placed an order for Google WiFi. I think this is a better decision to make than to wait for Eero. I'll give Google another try. Class A DHCP is not a big issue though than the loopback.
crispywisp thats the decision I had to make. this topic is 8 months old but there is other reddit that is almost year old.
Well that did it for me. I already had a [Google] OnHub. I just got 3 more pucks and moving to that. See-ya eero. I'll use you in bridge mode perhaps.
Just a question though. How is it that enabling a NAT loopback a security risk? I don't get it.
crispywisp When your router receives a packet addressed to your internal IP, it changes the destination to match the corresponding device on the internal network, assuming you have port forwarding set up. So here's why hairpin NAT doesn't normally work. A device with an internal IP, A, tries to use your external IP, C, to connect to a device with internal IP, B. A device A marks a packet (A->C) and sends it off to the router. The router realizes that since the packet is destined to the external IP, so it should change the destination to the corresponding device inside the network, B. So device B receives a packet (A->B). Device B then replies, so device A gets a packet (B->A). Device A freaks out because it expected a response from C but instead got a response from B. There's not really a whole lot you can do about that. The router has to NAT the packet from (A->C) to be (C->B) and then NAT the response (B->C) to (C->A). As you can see, it would have to NAT both the source and the destination, which isn't something you can easily do. Normally, you can only map the source or the destination or you lose track of what the packet is actually supposed to be. If you want that to actually work, you have to go through annoying processes of marking packets or some other convoluted system. Most implementations just mark packets. But any device on the network can mark its own packets however it wants, so whatever information is contained with the mark, any device on the network can spoof. Best case scenario, a device on the network can spoof being another host on the network to MitM your internal connections. In a worse scenario, which is more likely since implementations can never be bug free, a device on the network can probably spoof being whatever host they want, which is extremely bad news. As such, most enterprise grade hardware disables NAT loopback. For residential networks, it doesn't really matter too much, but the implementation of the feature is pretty ugly and it is somewhat of a risk, which is why eero's team might not be too fired up to work on this. Also, I'm not a network engineer so all of that could be totally wrong, but as far as I know, that's the problem.
A lead eero engineer thinks adding this feature will allow anyone on the internet to take over control of your entire network. Of course the reasoning is pretty far out there. I am going with lazy. Add a sub $100 EdgeRouter and put eero in bridge mode. Full control over everything and anything including hairpinning. :)
I decided to go with Velop instead of Google WiFi. seems like a better choice.
crispywisp please let us know what you think. I have the Google hardware already so I'll try that next. But my CEO built a house recently and used Velop. I setup the wifi there. Those nodes put out a VERY strong signal. I used Ekahau heatmapper and those nodes are the strongest I've seen. Easily twice the reach before considerable dB drop. They had other issues, like their UI lacks features. That stuff will come in time I assume/hope. The Orbi looks nice due to it's dedicated channel for internal communications. Overall the UI I thought was best is Google's. I look forward to a couple years when we get one that has the best features of them all. Cheers!
I get the potential security risk, but isn't that something that should ultimately be up to the end user? Add a NAT loopback toggle under Advanced Settings, default it to "off", and when I try to enable it, give me a confirmation window full of scary language about network security that will frighten off people who don't really understand what they're doing. I get my desired functionality, eero can truthfully say that they've made a reasonable effort to convince less tech-savvy users to leave it off, and people who have no interest in digging through Advanced Settings will never be exposed to risk. Problem solved.
NickP Sure. I ordered it from Amazon. It'll arrive on Sunday. That's what I heard about the Orbi for it's dedicated 5GHz channel. But I think it's only beneficial to mansions where you'll need more than 3 access points? But if you only need 3, or less, I think the lower end mesh wifi are enough.
go_robot_go That's another way to solve this problem too, which should've been done from the start. An option to turn it on or off.
crispywisp Yea that's a good point.
I received the Velop a day earlier than expected. I configured it, and it wasn't a great experience. Took me hours to get the WiFi running perfectly. I had to reset the main node a couple of times. First it couldn't get connected to the Linksys server, then I figured I had to put it in DMZ mode. Second, I couldn't get the second node connected so I had to do a full reset on both.
But after all the painful process, which took like 2 to 3 hours... really. Everything works perfectly. And loopback works as well. But there's no option to customize the DHCP (but, at least it's using the Class A). Also, the app isn't as perfect as Google and Eero, there are noticeable bugs and glitches, which is minor (updating device list). And it takes a bit to get the app to connect to the WiFi. You also can't see how much bandwidth a device is using.
But the good thing is that it has more advanced options you can't get from Eero and/or Google. VPN, QoS, Port Range Settings, Port Trigger, oh and this one, Enabling and Disabling ports you created.
There are some other options missing in Velop, but at least right now, everything works for me with it.
Also I'm having this weird behavior with the U-Verse modem. Somehow, U-Verse keeps kicking Linksys off DMZ mode. And when I try to add it back to DMZ, it would give me an error message like the Velop is in static IP and it's not allowed to be added in DMZ. And there's no option to disable static IP. I tried factory restoring the U-Verse, still having the same issue. I couldn't get both working properly. The only way I could get it working was to manually set the ports I need open from the U-Verse. It's weird I contacted U-Verse support about this and he too couldn't figure out what was wrong so he is sending me a newer modem that has a "bridge mode".
+1 for NAT hairpin. It is ridiculous to require either an internal DNS server or additional hardware (separate router) to enable this functionality. I bought Eero because I was tired of having a router I needed to reconfigure, troubleshoot & restart all the time, and refuse to add that back in to the mix.
The smart home becomes dumb, and the camera system becomes overly complex for any non technical person (my wife) to connect to.
+100 for NAT hairpin. I can't remember the last router I had that couldn't do this. It worked perfectly with my Airport Extreme, with the Airport before that, with the cheap-#^$%$ Xfinity router before that, with... In fact, it's so widely available it never even occurred to me that a premium-priced "make-your-life-easy" wifi/router wouldn't have that feature. Not having this feature might have been a reasonable choice, oh... maybe a decade ago (which is around the time I first got my network set up that way). Not having NAT hairpin in 2017? Really???
For some of my uses, I can work around the issue by having two separate configs in various apps—named like service@home or service@outside. But that won't work so well for, say, my IMAP server. I have yet to figure out how to convince any useful mail client to switch between addresses for the IMAP server without treating the two addresses as completely different accounts. That's a show-stopper! More generally, the various personal cloud services I run for the family really ought to have the same URLs no matter where they're being accessed from. I'm stunned that the eero can't do this!
At this point, I'll probably experiment with adding a local internal DNS server as yet another service to configure. If that works smoothly, things will be OK. If not, my shiny new Eeros go back to Amazon and get replaced with a system that meets my needs.
I'll be sure to follow up with results, to add to the community's knowledge base.
+1 for me on this topic too. I have a Synology Diskstation running a server that used to be accessible via my domain name from within my home on an Airport Extreme. It was very disappointing when I discovered that no longer worked with my Eero setup. Seems like a very basic feature considering every router I've had before Eero supported it (Linksys, Dlink, Netgear, and Apple). Please add this feature.
+1 for this too. I'm tired of this everytime I forget to shut wifi off:
I'm curious if the newly announced Eero Pro will support this? If so, is the first gen going to be left out?
swede76 it does not. I called support. Don't rush to buy, wait for it to be a feature.
I would love to pick up two of those new wall plug units, but I can't invest any more into this platform. Deleted the discount email.
Adding onto the pile of yet another new, previously-happy eero customer who got bit debugging port forwarding overnight. This is such a sad oversight by eero. This is a trivial change that, when done properly, doesn't have any security ramifications. Please, please, please support NAT loopback.
Following up to my post above. Setting up an internal DNS server was reasonably straightforward. My internal server is a Mac running the Server app. Here's what I did:
- Configure OS X Server so that it runs a DNS server for a single domain: my.fqdn.wherever
- Tell the DNS pane that the only host in that domain has the local address (e.g., the inside-my-network address) of my server
- Tell the DNS pane to use my Internet Provider's DNS servers for all other requests.
- Use the Eero app to reserve the IP address for my Mac server.
- Use the Eero app to use my internal server as its DNS server, with my Internet Provider's DNS server as backup. The config values I replaced used my ISP's primary and secondary DNS servers.
- Turn on the OS X Server's DNS service.
- Let everything restart that wanted to.
There was still some small delay getting things working, because various devices had cached values for various DNS settings. Taking those devices off the network and then back on fixed that problem.
Now, I'm back to using the same FQDN to access my services whether I'm at home or out and about.
Kudos to Apple for making the settings in the Server App so simple that I could do it easily. All I needed was to think about the effect I wanted, and it was straightforward from there.
- Status Implemented
- 2 yrs agoLast active