Addional VLANs at client site can't use the VPN link

I have an new location about to open up in January with that start of the spring term. This is a purchase of a building more or less adjacent to campus, and not new construction. Unfortunately, the fiber run to the building will not be completed until late March. In the mean-time, we'll have to rely on a basic cable internet service.

To make this work I need certain internal services from my main location to be available to the new site: our Unifi controller, a few internal web applications, print server, etc. We already run Untangle at the main site, and my plan is to setup a temporary workstation at the new site, with the main site running the OpenVPN app in server mode and the new site running the OpenVPN app in client mode.

And this is (almost) working! Devices on the default vlan at the remote site can see devices on the exported networks for the main site.

My problem is we need more than just the default vlan, and devices on additional vlans at the new site cannot see anything from the exported networks for the main site.

Additional vlans at the new client location are setup directly in Untangle as tagged child interfaces from Internal. From what I can see I have a complete routing table, though as long as I've been doing this I haven't had to read routing tables often enough to be very good at it; still, I think if the route to the main location were bad the default vlan wouldn't work, either.

The client site is a new Untangle installation, with almost everything still at the defaults. Any ideas what I might have screwed up?

Why did you use Openvpn and not ipsec ?

Because this is a temporary 3-ish month (assuming no construction setbacks) installation, with the remote client running entirely on the basic/free tier and reclaimed hardware; IPSec is a paid module. (It's not just the money... structurally, I'd rather not go through our procurement process for this.)

Also, Untangle<=>Untangle OpenVPN tunnels are (supposed to be) very easy to get working.

Did you try tunnelvpn too. No idea if it will work but worth a try. I assume you exported the networks you want.

I actually tried that first (OpenVPN on the server/main location, TunnelVPN on the client/new remote location), and for some unknown reason the tunnel always showed DISCONNECTED, but the exact same configuration worked for the OpenVPN app. Didn't even need to re-download the zip file. So OpenVPN it is.

Four more things to add:

First, the additional vlans at the new site do have access to the default vlan, at least to the point of being able to access the Untangle server system on that site via its default Internal interface.

Second, to get Unifi devices working for the new site I have to first adopt them on the main site, and then set a static IP address on the default vlan for the new site while still connected at the main site. At this point I lose the connection, but when I then bring the device to main site and plug in into the network it will boot up and work there as expected, including configuration changes. I can work around this, but it's annoying as I have 16 devices to setup for this location.

Third, DNS resolution into the main network is working, but this is because the Untangle device at the new site is the DNS server for the site, it's on the default vlan, and it's using the DNS server on the main site as it's source (with fallback to a public source if that's not available).

Fourth, I can't get failed connections to even show up in the session viewer. If I try to open an internal web page from a device on an additional vlan at remote site, given the DNS resolution succeeds I would expect a connection attempt from the device to get to untangle and be recorded there, even if it goes no further, but I see nothing. The only exception to this is I can use nslookup from a remote device to target the DNS server at the main site. Those sessions do show up, and seem to target the correct interface. However, no traffic moves and any hosts I try to resolve this way will time out. Additionally, I can see ldap sessions attempting to reach our domain controllers from a domain-joined laptop at the site. These sessions also seem to target the OpenVPN interface, but the traffic numbers all show 0.

Quote:

---

Originally Posted by jcoehoorn

Because this is a temporary 3-ish month (assuming no construction setbacks) installation, with the remote client running entirely on the basic/free tier and reclaimed hardware; IPSec is a paid module. (It's not just the money... structurally, I'd rather not go through our procurement process for this.)

Also, Untangle<=>Untangle OpenVPN tunnels are (supposed to be) very easy to get working.

---

Ipsec tunnel takes like 2 min to setup. I hear you though, free version doesn't give that option.

Untangle to Untangle OpenVPN site to site tunnels ARE easy to get working.

But... they are also VERY easy to screw up, especially when you're doing what you're doing.

So...

Two things to check, both on the server side.

OpenVPN settings -> Server Tab -> Exported Networks Subtab

The list of IP networks here must be complete, this list builds the routing table for all VPN clients (including the site-to-site), this is where they all get their routes from. If the IP range isn't in this list, the VPN won't carry it. So you need to include all IP ranges the VPN needs to access AND will be accessed by.

If you want ACLs, use the Firewall App.

The second thing, is under the Remote Client's subtab, find the client you made for the far side Untangle. Edit it...

See that Remote Networks box? It can include a comma separated list of IP ranges! But just like everywhere else... forget the space! eg: 10.120.0.0/24,10.121.0.0/24

That list needs to have all the IP ranges on the far side of the Tunnel, so your OpenVPN SERVER SIDE device, knows where to route those ranges.

Get your routing sorted out, then worry about services. I'll bet you forgot to include all the IP ranges on the far side in the client configuration. Why do I assume that? Because that's what I do to myself...

Quote:

---

Originally Posted by sky-knight

I'll bet you forgot to include all the IP ranges on the far side in the client configuration. Why do I assume that? Because that's what I do to myself...

---

Yep, this was it! Also, I had a conflicting route on the Untangle server at the main site because I was re-using an old obsolete vlan tag which had a static route left behind (Inter-vlan routing at the main site is handled by a different device, so Untangle at the main site has static routes for vlans instead of child adapters. I'm thinking about changing this, so I can offer students -- especially Playstation Network users -- some limited UPnP).

Based on this I will also need to change a planned IP range for one of the Wifi networks at the new site. I want to use the same vlan tag to keep Unifi setup simple, and I had planned to use the same subnet as well (but a different region within the subnet), but I can change that easily enough.

It still looks like I might need to adopt and set manual IPs for the Unifi devices on the main campus first, but I'm not sure... I also need to figure out now why dhcp, which was fine a few hours ago, stopped working on the default vlan (other vlans are fine).

The good news is there should only be static infrastructure on this default vlan, so if I have to set a few static IPs I can live with that. At least I don't have to go with my other work-around, which was forwarding public IPs to internal servers (like the domain controllers and file servers), where the forward rule was restricted to the WAN IP from the new site. I really didn't want to do that.

I always have DHCP active, I don't do static anything anymore. Especially with Unifi gear.

If I want to move a controller, I should just have to change a DNS record and watch it happen as DNS time's out. But it's also nice to use the DHCP option method, because it means I can have a different controller on each VLAN if I want. Handy if you're multi-tenanting an Untangle protected network.

Quote:

---

Originally Posted by sky-knight

I always have DHCP active, I don't do static anything anymore. Especially with Unifi gear.

If I want to move a controller, I should just have to change a DNS record and watch it happen as DNS time's out. But it's also nice to use the DHCP option method, because it means I can have a different controller on each VLAN if I want. Handy if you're multi-tenanting an Untangle protected network.

---

No DHCP / IP reservations ?

Quote:

---

Originally Posted by dashpuppy

No DHCP / IP reservations ?

---

Oh I use those all the time, but that's not a static configuration. Actual static IP configurations to me are bonkers, unless it's a DHCP server, or a Domain Controller EVERYTHING is DHCP, and if it needs to not move reservations ensure they don't. That way I can renumber by configuring a few devices and a DHCP scope, and not be stuck going to a hundred devices manually.

I'm using the DNS method for discovery (A record for unifi on the local network). And DHCP is active, but devices aren't picking up an address. It was working a few hours ago.

But now I have a couple days off. More on Monday when I'm back (this all needs to go live that Friday :/ ) The building had absolutely no networking at all when we got it... I ordered 12 boxes of cable and personally pulled more than 3/4 of it over the last two weeks, so this is time well earned.