There are other members of the Ubiquiti EdgeRouter family that use this same v1.9.1 firmware, so this article likely applies to those folks as well, including:
- ERLite-3 and ERPoe-5
- ER-8, ERPro-8, and EP-R8
- ER-X, ER-X-SFP, and EP-R6
Within about 30 seconds of getting all my Windows and Linux PCs and VMs talking to each other on a firstname (short name) basis last summer, I fell for my new Ubiquiti EdgeRouter Lite, aka UBNT ERLite-3. This polite behavior was with plain old DHCP for these systems, no manual DNS tinkering on the clients required. Finally! Something no consumer router could do, running my home network and my home lab, together. When coupled with my new eero Wi-Fi in bridge-mode blanketing my home in as-fast-as-wired speeds, both my VMware VCSA 6.5 appliance and my family were finally all very happy indeed.
It wasn't hard to configure, and future articles will cover my exact configuration process, all using the web based GUI. I'd say it required intermediate skills to figure out, but once I get the details published, any home lab enthusiast can turn this pro-sumer router/ SOHO router into a consumer router that's no harder to use than the vast array of consumer routers out there. Only way faster, more better.
All that said, no networking product is perfect. The web changes. Regular firmware updates are today's reality. The minor bumps in the road that affected my configuration these last 7 months of ownership included:
firmware release 1.8.5 worked well, including L2TP over IPSec VPN tunnel functions from native Windows 10 and iOS VPNs
- firmware release 1.9.0 worked well, except my occasionally-used L2TP over IPSec tunnel server feature wouldn't allow clients to reliably connect after that first successful connection
- EdgeMAX EdgeRouter software release v1.9.1
by Ubiquiti Employee UBNT-afomins 12-16-2016 07:09 AM - edited 12-22-2016 08:49 AM
I was relieved when I spotted this release. Just in time for my planned vSphere 6.5 follow-on to my popular how-to videos! I'm planning to use proper DHCP and DNS server configuration, much better than host file hacks on each system. This router as the short name, FQDN, and reverse lookup that VMware VCSA requires without the need for Active Directory, all for well under $90 USD. Also capable of processing a million packets per second, future-proofing my home for my next bump up in speeds from my current 300Mbps down/30Mbps up Cox Communications DOCIS 3.0 connection.
Of course, I quickly read the 1.9.1 release notes, and found comments in the forums that the following shortcomings are still present:
- the OpenSSH VPN server doesn't support hardware offload (it does support L2TP hardware offload, but L2TP is less secure)
- using dnsmasq for DHCP instead of the default DHCP server results in blank DHCP Lease information in the GUI
These weren't show-stoppers for me. I was just really wanting to be sure I was going to have a set of how to install vSphere 6.5 instructions without having to recommend a backlevel firmware to folks. I was also hopeful that 1.9.1 would offer an improved IPSEC VPN connection experience too. So I went and downloaded 1.9.1 and installed it, simple enough:
At first, good news! L2TP over IPSec now worked every connection, full VPN or split, from native Windows 10 and from iOS.
But minute later, a new problem surfaced. I tried to visit my VMware vSphere 6.5 VCSA VM by short name:
which used to work just fine, but now failed. Uh oh.
Did a bit of the usual nslookup and ping troubleshooting, and experienced the following:
C:\>nslookup apc Server: ubnt-home.lab.local Address: 10.10.1.1 Name: apc Address: 10.10.1.3 C:\>nslookup apc.lab.local Server: ubnt-home.lab.local Address: 10.10.1.1 Name: apc.lab.local Address: 10.10.1.3 C:\>ping apc Ping request could not find host apc. Please check the name and try again. C:\>ping apc.lab.local Pinging apc.lab.local [10.10.1.3] with 32 bytes of data: Reply from 10.10.1.3: bytes=32 time=2ms TTL=60 Reply from 10.10.1.3: bytes=32 time=2ms TTL=60 Reply from 10.10.1.3: bytes=32 time=2ms TTL=60 Reply from 10.10.1.3: bytes=32 time=2ms TTL=60 Ping statistics for 10.10.1.3: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 2ms, Maximum = 2ms, Average = 2ms C:\>
So off to the friendly Ubiquiti forums I went, signing up for a free account, and posting my question there:
- DNS resolution of shortnames (mostly) broken after I upgraded my EdgeRouter Lite from 1.9.0 to 1.9.1
12-27-2016 10:07 AM by c3f23686
To my amazement, a proposed workaround was posted by lanefu within about 10 hours, and it worked! For folks that have multiple DHCP servers configured, see also joemoor's comment. It's amazing the level of problem determination details that several folks presented, basically a free root cause analysis to the problem I was experiencing. Not something you see everyday.
There were also quickly reports of other folks noticing the same problem, adding to my new forum thread, and even a Ubiquiti employee chiming in
Looks like it the same issue as described here -> https://community.ubnt.com/t5/EdgeMAX/Edgerouter-dns-is-giving-me-the-sh/m-p/1771012#M140746
Bug ticket has already been created.
For my lab with a local domain of
all I needed to do was the following fix.
More of a workaround really, only needed only until the next firmware release:
- ssh into my router, which is at 10.10.1.1 in my home, and authenticate to an admin account such as the default username
and press Enter
set service dhcp-server global-parameters 'option domain-name "lab.local";'
and press Enter
This saves the change to the working set of the router. Optionally, now you can take a moment to do a
dhcp /renewon a Windows client, to be sure you're happy with the change, and to re-test that short name lookups such as
ping vcsa(or some other home networked device with a DHCP reservation) functions.
This saves the configuration change to persist across reboots of the router, and across future upgrades of the router. It makes the one line DHCP configuration change permanent.
Now I have a 1.9.1 that behaves just like the prior releases, but now an IPSEC VPN server that is reliable too. Yay, I can move onward to other things.
Glad that little bump in the road wasn't hard to go over. Basically a one-liner workaround is needed only until the next release arrives, which is probably a few months away.
This overall Ubiquiti support experience is so vastly different from the many consumer routers I've used, so very much better. Real useful community and employee support, for free. This is a very comforting feeling. Know I know why so many folks feel good about their Ubiquiti products.
Hopefully my family and my router can now glide right through 2017 and beyond, with minimal fuss. Hopefully this article helps others glide right through with me!
- Motorola Arris SB6183 16 Channel DOCSIS 3.0 Cable Modem, future-proof through 686 Mbps?
Nov 14 2016
Home Lab Fundamentals: DNS Reverse Lookup Zones
Jun 13 2016 by Frank Denneman at frankdenneman.nl
The recommendation is to use the FQDN.
Ensure that DNS reverse lookup returns an FQDN when queried with the IP address of the host machine on which vCenter Server is installed. When you install or upgrade vCenter Server, the installation or upgrade of the Web server component that supports the vSphere Web Client fails if the installer cannot look up the fully qualified domain name of the vCenter Server host machine from its IP address. Reverse lookup is implemented using PTR records.
If you plan to use an FQDN for the virtual machine or physical server, you must verify that the FQDN is resolvable.
- Why the use of DNS “short names” should not be used as a strategy
Jun 22 2012 by Michael at Zebulak