Teleport VPN - Ubiquiti's WireGuard

Ubiquiti recommends Teleport for VPN purposes in the UniFi Dream Machine. Activating this feature requires remote access to be enabled on the controller followed by Wifiman in the Network application. While this is straightforward enough for most setups, there are certain situations that trip up this flow. In my case, one of the power failures ended up corrupting the UDM - Internet access from within the network worked, but the web UI was inaccessible, SSH attempts timed out, and Teleport would simply give up. The unit had to be resuscitated via the recovery IP using a firmware image downloaded offline. After recovery, the UDM was accessible over the local network and Internet access worked. However, it was not visible either in the mobile app or the cloud-based management portal as remote access was disabled (and couldn't be activated despite repeated attempts). It turned out that the inability of the unit to communicate with the default NTP servers from behind the CGNAT had resulted in the date / time of the unit being set based on the firmware build date. Fixing this manually allowed the remote access feature in the controller to be activated.

Enabling WiFiman is done in the System section of the Network application.

After taking care of these two aspects, Teleport invites can be generated under the 'Teleport & VPN' section of the web UI as well as the mobile application.


Teleport Invite Generation using Cloud Management / Local Web UI

Teleport Invite Generation using the UniFi Network Android App

The advantage of using the Android app to generate the invite link is the ability to directly open it with the WiFiman app to get into the target network. Upon accepting the invite in the app, the connection is available for activation as long as the source gateway (UDM in this case) has a connection to the Internet.

The Teleport functionality in the UDM currently forces the invited device into the 192.168.2.0/24 network. This is currently not user-configurable. In my case, this was not a show-stopper, as the UDM automatically took care of enabling seamless communication between the primary 172.16.0.0/24 subnet and the VPN subnet.

In the first few days of grappling with CGNAT, I attempted to set up a dedicated Android device to act as a Teleport client for other devices in the US to connect to. Unfortunately, except for my Pixel 6a, none of the Android devices at my disposal (I even tried setting up an old NUC with Bliss OS) could help in this aspect. Either the Teleport feature in the WiFiman app was not available for the old Android version, or, the connection proved to be extremely unstable. After a fruitless couple of days, I gave up completely on this approach.

The Teleport feature did end up serving me well beyond the attempt, though. Throughout the course of future experiments, I had Teleport as a fall-back to be able to SSH into the UDM network and configure the gateway as well as machines local to that network.


SSH over Teleport via an Android Intermediary
(From L to R) Clumsy SSH access, Activating SSH server on the Pixel 6a, Allowing ADB access

As a good security measure, Ubiquiti does not allow SSH access to the UDM over remote access by default, and the only safe way to achieve this is to create a secure tunnel into the target network prior to attempting a SSH login. Initially, I used the termux app to directly SSH into the UDM (after connecting via Teleport, obviously). Executing shell commands over a mobile keyboard turned out to be frustrating exercise. Fortunately, it is possible to run a SSH server on an Android phone and connect to it via ADB. With the Teleport connection active in the background, it became easy to access the UDM over SSH from a proper desktop.


SSH over Teleport via an Android Intermediary using a PC

Prior to starting the whole exercise, one of my goals was to avoid any sort of third-party relay server or cloud service in the communication between the USG Pro 4 and UDM. However, after exhausting all possibilities within my limited networking knowledge, I regretfully started to look at options involving third-party services. <a href="https://www.vpn.net/'>Hamachi, Tailscale, and ZeroTier appeared to be popular, with the most common use-cases tending to be connection between individual systems. Of these three, Tailscale and ZeroTier had multiple write-ups and guides, with some specifically talking of site-to-site setups involving Ubiquiti gear. Armed with these guides, I took the plunge into ZeroTier first.

The CGNAT Spanner in the Works Activating ZeroTier - A Virtual SDN
Comments Locked

35 Comments

View All Comments

  • bradh352 - Wednesday, December 21, 2022 - link

    First thing that comes to mind is why you didn't attempt to use ipv6 addresses to create the ipsec vpn? I know comcast/xfinity supports ipv6, and I'd have to imagine anyone deploying CGNAT for ipv4 is providing a public ipv6 address, thus negating any of the issues described.

    Typically these ipsec vpn sessions are in tunnel mode which means they can transport both ipv4 and ipv6 packets, even if the public ips being used are only ipv4.

    Maybe ubiquiti doesn't support this in their UI for some reason? The underlying system should be capable of this though (strongswan afaik).
  • edzieba - Wednesday, December 21, 2022 - link

    "I'd have to imagine anyone deploying CGNAT for ipv4 is providing a public ipv6 address"

    Sadly, such a sane and customer-oriented approach remains firmly in your imagination for the vast majority of ISP CGNAT deployments. Most commonly, IPv6 will just not be available at all.
  • ganeshts - Wednesday, December 21, 2022 - link

    Airtel does provide an IPv6 address with their CGNAT configuration. Sadly, there is no IPv6 support on the Comcast front over here in the US, and Ubiquiti doesn't support IPv6 in their VPN configuration either (at least from the web UI perspective).
  • ViRGE - Wednesday, December 21, 2022 - link

    "Sadly, there is no IPv6 support on the Comcast front over here in the US"

    Huh? Comcast was one of the very first major US ISPs to implement IPv6. They've been running a full dual stack implementation for nearly a decade now.

    https://web.archive.org/web/20160329232139/http://...
  • cgull.at - Wednesday, December 21, 2022 - link

    I was amused to see that the IPv6 post I was contemplating was ninja-ed before birth by the very first post.

    I suspect the reason Ganesh isn't seeing IPv6 is his "ancient cable modem". Very likely it's not DOCSIS 3.0 or later and doesn't do IPv6. The DOCSIS 3.0 standard was released in 2006, 3.1 in 2013. Upgrade, already!
  • cgull.at - Thursday, December 22, 2022 - link

    Also: Comcast was one of the major leaders and instigators of "World IPv6 Day". That was back in January 2012. As I recall, somewhere around 50% of their customers were IPv6-enabled then.

    Why? They were running out of IPv4 addresses to give to customers, which also explains why Ganesh is seeing CGNAT now.

    My ISP had (and probably still has) IPv4 addresses in reserve. They haven't enabled IPv6 for consumer internet service yet.
  • dersteffeneilers - Saturday, December 24, 2022 - link

    with my ISP over in Germany, you can use both IPv4 with CGNAT and IPv6, but you only get an IPv6 address if you already have an IPv4 one. Ridiculous, I can't imagine a technical reason for that.
  • Leeea - Thursday, December 22, 2022 - link

    Nobody in their right mind uses ipv6 unless they absolutely have to.

    They really should come up with another standard that is less ideologically pure and way more practical.
  • ballsystemlord - Thursday, December 22, 2022 - link

    Could you expand on that a bit more Leeea?
    It's unclear to me why an IP addressing scheme would be impractical as a result of ideological purity.
  • jack21159 - Thursday, December 22, 2022 - link

    IPv6 was made for ultra-nerd and it's difficult to understand.

    I mean, IPv4 still is a learning curve, but at least it's easier to understand. Most people don't know how to segment a network (/23 , /24) or do custom routes, but that's fine you can use it even if you don't understand all the concept.

    IPv6 by contrast, no. a course is needed to understand that.
    they could have just added a few Bytes to the standard 4 Bytes scheme (ie 255.255.255.255.255.255 for exemple) But nooo let use hexadecimal, something than only computers and ultra nerds understand !

Log in

Don't have an account? Sign up now