It would be useful if the VPN server could work behind a NAT device. Of course, ideally this would be the edge device, but it’s not always the case. There are multiple use cases. Mine at the moment is that I partially set up just the basics for a site, just enough to get everything online and updated, but I won’t be back onsite for a little while and there are other local devices I need to access to continue getting the entire system setup. I wasn’t going to dare throwing the Comcast modem into bridge mode until I knew everything was functional within the Alta network, which means the Route10 has the private 10.x.x.x WAN IP.
I tried to connect via VPN, but as I suspected, the Alta VPN is pretty basic, needs it’s WAN exposed. I know it’s possible to do, some others do it.
Another use case could be that only a particular VLAN needs VPN access and there’s a more robust edge device in place. This would allow sticking a Route10 on the applicable VLAN and presto.
We actually do not currently restrict the listen interface for the VPN servers, they work perfectly fine behind double-NAT. However, I think I know where the confusion lies, and this isn’t in our documentation yet (it will be, creating a card for it after this post).
The id.ddns.manage.alta.inc hostname format will resolve to a physical WAN interface. Do note that this is the literal IP on the interface itself, hence why you’re seeing the rfc1918 address. There are some variations to this hostname that I would like to make you aware of, one of which will help here assuming the upstream gateway is properly configured to forward to the Route10.
So main hostname again is: id.ddns.manage.alta.inc
- To return the
wan IP (WAN 1): 1.id.ddns.manage.alta.inc
- To return the
wan2 IP (WAN 2): 2.id.ddns.manage.alta.inc
- ^… etc, for WANs following their logical number, not metrics/weighting.
- To return the current external IP, not the literal interface IP, you would use:
public.id.ddns.manage.alta.inc
It’s that last one which you want to leverage in your case. Try adding public. to the hostname. You could also use the external IP if you knew it.
Thanks, that’s helpful and good to know. It’s not exactly what I was shooting for here. I’m talking about the Route10 creating a pathway through the edge device to be reachable from a remote VPN client, that is, without touching the edge device and setting up port forwarding. I know Meraki has this option and I don’t recall if Ubiquiti does.
Ah, well I may have good news. We have plans to add support for Tailscale which is a mesh based WireGuard service where an external relay is used to communicate through. I imagine that would at least achieve a similar end result, if it wasn’t a similar architecture. Unfortunately I have not heard timelines, other than it is planned.
Would that better align here?
2 Likes