Untangle v16.0 Beta has started

Sky-Knight

Well-Known Member
Reaction score
5,513
Location
Arizona
If you're like me you're still trying to get all your stuff to v15.1! But now v16.0 is on the way.

The upgrade from v15.0 to v15.1 is a bit ugly, but the upgrade from v15.1 to v16.0 should be pretty clean. There is no kernel change, and no change to the OS.

What's changed?

Untangle v16.0 finally supports EFI booting, so no more BIOS emulation is required. Though if you've dealt with Debian on this you know how touchy it is, it's a critical feature but not something I'd call a cure all.

The big deal? Untangle v16.0 is coming with a brand new VPN option, Wireguard.

Wireguard is simply incredible technology, everyone on this board should be at least aware of it. It's lean, fast, easily managed, and simply doesn't care about network connectivity. What do I mean? Well, think about how Bittorrent works, you've got a tracker and members of the swarm. The tracker deals with keeping the swarm moving data around. Wireguard works very similarly, so you can cloud hose a wireguard service, and have things connect to it, the rules imposed by the tracker determine what tunnels get setup as needed to achieve connectivity. It's no longer a hub and spoke, it's a full mesh down to the individual endpoint. If that logic even applies, again it's a managed swarm.

So it's easier to manage relative to OpenVPN, which is already easier to manage relative to IPSec/L2TP.
It's more secure than the above technologies.
It's also FASTER than the above technologies.

And if that wasn't enough, at some point Microsoft has promised us a Wireguard VPN client for Windows native. Which means down the road you'll be able to use inTune policies, or GPOs to configure devices to use Wireguard VPN targets.

For now you must use the 3rd party client: https://www.wireguard.com/install/ Which comes as an MSI so easily published via InTune or GPO.

I don't have details on configuration yet simply because I haven't spent any time with Untangle's specific implementation. More data as it comes!

Oh, and if it wasn't clear, I see not reason to restrict upgrades at this time. If you're already on v15.1, moving to v16.0 should be automatic and painless.
 
I decided to give Wireguard a spin and setup a DigitalOcean droplet running Ubuntu Server 20.04. Did all the required configuration for a standard Ubuntu Server config. Got Wireguard up and running. Installed the Wireguard app on my iPhone and Mac connected without issue for a couple of weeks to my Wireguard VPN.

Ran an update on the Ubuntu Server 20.04 and since then it's been a constant "Handshake did not complete after 5 seconds, retrying..."

Searching web for solution to issue, found no fix as of yet. This gives me some caution implementing it in a production environment. Could be Ubuntu messing up things? Probably should have gone with a Debian install instead.

gpg
 
That's Wireguard's generic I can't connect error. So you need to double check something isn't mucking with your listen port on the way into the server. Also, you need to verify the client's configuration has the correct IP address and listen port.

It could even be something even more stupid...

Did you forget to tell Ubuntu to auto start the service? Because I'll bet if you look, the service probably isn't running. There are a TON of tutorials out there that don't plumb the depths of systemd properly... it creates this mess.

Untangle wouldn't have that problem because the platform manages it for you.
 
Last edited:
Did you forget to tell Ubuntu to auto start the service?
No, I have it running at startup. UFW is configured to allow UDP port I assigned to Wireguard. It's running and yes the iPhone Wireguard app is configured with the correct public IP and port number. Just keeps on trying handshake every 5 seconds.

To confirm Wireguard is running I issued wg and it shows that the wg0 is active.
 
Interesting, the next step would be to do some TCPDump to see if the packets are actually making it to the NIC. I'm not talking about wg0 here, I'm talking about eth0. Can you see traffic landing on the UDP port in question?

If the answer is no, the server is fine... and perhaps your cellular provider is blocking.
 
Did TCPdump. Yes, packets are making it to eth0.
UDP on the correct port. Something wacky on the server.
 
Very strange, so yeah now you're down to authentication errors. Because yeah... those are the same blasted error message too.
 
Wow, something very fishy going on with DigitalOcean or maybe Marvin Martian decided to do some mischief. After a full day yesterday I finally took a look at my /etc/wireguard/wg0.conf file. Hmm, all the peer settings were gone. I did not delete them and when I issued the wg set wg0 peer command I got a AllowedIP has nonzero host part... Reset wg0 issued command again and it added the peer to the wg0.conf file but it had the incorrect IP. Adjusted IP and tried my iPhone. Finally got connected.

Then tried adding back in my Mac, tried the wg set wg0 peer command again. No errors, checked the wg0.conf and the peer was not listed. Hmm, added the setting with nano wg0.conf and tried to connect my Mac to Wireguard VPN and now it too works.

Really strange stuff. Anyway it's now working and I will be making a backup of the wg0.conf file. Or just spin up a new on on some other cloud provider.

Thanks,
gpg
 
Back
Top