Untangle and OpenVPN issue.

[gpg]

Hey Technibble,

I have 10 Untangle NG Firewalls that need deployment in the near future. I have one deployed so far and am trying to get OpenVPN to play nice. So far not happening.
Untangle version is 14.1.2.20190401T184625.3e1709127f-1stretch.
Problem found in OpenVPN log file is UDP link local: (not bound).
I have removed OpenVPN and reinstalled twice, still same error.
Any ideas as to what I could try next.
I have the following private networks.
10.10.10.1
172.16.0.1
192.168.14.1
192.168.2.1 VLAN tagged 110.
The current OpenVPN IP is 10.0.0.0.
When I setup the OpenVPN I checked enabled on all networks and the NAT OpenVPN Traffic is checked. I also required a Username/Password Authentication via Local Directory. I made no changes via the Advanced tab.
I did create a user in the Local Directory > Local Users.

Any help will be greatly appreciated.

Thanks,
gpg

 

[Slaters Kustum Machines]

When you run the OpenVPN client are you running it as admin?

 

[Sky-Knight]

Need more specific information... Untangle OpenVPN literally "just works".

The error you're getting is coming from where? It seems like you're talking about an OpenVPN soft client on something, but then you're talking about 10 firewalls as if you need site-to-site... I'm confused.

If you're trying this from a Windows 10 1903 end point, you'll need to install the more recent OpenVPN Community client over the top of the one Untangle provides.

The OpenVPN client no longer requires admin rights, the service does the lifting now via the task tray icon. The error you've found seems to be saying the virtual NIC driver is missing, on Windows that's the TUN/TAP driver, again see above. But if you're on Win10 1809 or older, what ships with Untangle works fine, the only further suggestion I have in those cases is to disable 3rd party AV software before installation.

 

[nerd2u]

Sounds like perhaps the port is in use by something else.

Sent from my SM-G870W using Tapatalk

 

[gpg]

When you run the OpenVPN client are you running it as admin?

Tried running as admin, same result.

 

[gpg]

Need more specific information... Untangle OpenVPN literally "just works".

The error you're getting is coming from where? It seems like you're talking about an OpenVPN soft client on something, but then you're talking about 10 firewalls as if you need site-to-site... I'm confused.

If you're trying this from a Windows 10 1903 end point, you'll need to install the more recent OpenVPN Community client over the top of the one Untangle provides.

The OpenVPN client no longer requires admin rights, the service does the lifting now via the task tray icon. The error you've found seems to be saying the virtual NIC driver is missing, on Windows that's the TUN/TAP driver, again see above. But if you're on Win10 1809 or older, what ships with Untangle works fine, the only further suggestion I have in those cases is to disable 3rd party AV software before installation.

Error from W10 Pro version 1809 OS build 17763.557 using client provided by Untangle and PopOS latest version same link local not bound error.
No 3rd party AV software installed.

 

[YeOldeStonecat]

Just a note here...my Carbon laptop is running Windows 10 the latest (currently) 1903
I just downloaded the Untangle OpenVPN client from a school client, their Untangle is 14.1.2
Launched OpenVPN client just fine, connected just fine. All working normally.

 

[gpg]

Sounds like perhaps the port is in use by something else.

Sent from my SM-G870W using Tapatalk

I do have an Ooma VoIP system that has an OpenVPN service running on port 1194 but on a different private IP space. Possibly because the public IP is pointing to two different private IPs for the same protocol I should change the protocol number of the OpenVPN server for Untangle and create an access rule in the Untangle pointing to the OpenVPN server on the Untangle?

 

[Sky-Knight]

@YeOldeStonecat, if you ever had OpenVPN installed before the upgrade, the laptop will work. But some and only SOME mind you of the units I've been testing with won't work with the released client direct from Untangle. This is pretty normal stuff OpenVPN goes through every time Windows upgrades, and one of the reasons why I keep my clients almost six months behind on feature releases.

So long story short, your experience doesn't surprise me.

Link local not bound is not a server error, it's a client error. It means the client isn't connecting to an operable server.

Now, if that public IP address has another OpenVPN service running on it via port forward, that would explain it. You cannot move Untangle's OpenVPN port, it must be UDP 1194. You can confirm connection details by looking in the config folder under OpenVPN in program files. There's a .ovpn file in there, edit it with notepad, you're looking for a remote line. That line should have the IP address Untangle is living on, and port 1194. If that IP address is wrong, then there's a server configuration problem but you can make a quick edit to see if the services are happy.

If you have to make that edit, come back here and report what change you had to make, I can point you at the place in the Untangle UI to kick to sort it.

Note, you CANNOT test Untangle OpenVPN from inside the Untangle protected network, there is an access rule preventing access. Because routing loops are bad...

 

[nerd2u]

Are you trying to connect from the internal or external network?

Assuming you have port forwarding done correctly?

Sent from my SM-G870W using Tapatalk

 

[gpg]

Are you trying to connect from the internal or external network?

Assuming you have port forwarding done correctly?

Sent from my SM-G870W using Tapatalk

External via LTE from mobile phone hotspot.

 

[Sky-Knight]

Perfect, that's the best test. Did you check your remote line in the client configuration to ensure the right IP address is being used?

Have you verified that IP address is NOT forwarding UDP 1194 to something else?

 

[gpg]

Perfect, that's the best test. Did you check your remote line in the client configuration to ensure the right IP address is being used?

Have you verified that IP address is NOT forwarding UDP 1194 to something else?

Remote line has correct IP address. It's most likely my Ooma VoIP since it too has OpenVPN server service running on port 1194.
Apparently the port number can be changed just have to be careful with the new access rules. Looks like the access rule has to be done via command line. See https://forums.untangle.com/openvpn/40134-openvpn-moving-port-changing-protocol-fails-work.html

I will have to try this later since every time enable/disable the OpenVPN it kicks me out of my SSH connections to work. That stinks and makes the wife really angry! Yikes!

 

[Sky-Knight]

@gpg, I'm the same SkyKnight on those forums... that thread? It's WRONG, there is no supported way to change the OpenVPN port, you cannot use UDP 1194 in two places.

If you have another OpenVPN service using that port, you must use a second IP address. This means probably taking your current primary address, making it an alias and giving Untangle a new primary WAN IP address. This frees you to convert the port forward used for the other OpenVPN to destination address, instead of destined local, maintaining it on the address it's already using, and moving Untangle to the new IP address for its use.

There is no other supported solution.

 

[gpg]

@gpg, I'm the same SkyKnight on those forums... that thread? It's WRONG, there is no supported way to change the OpenVPN port, you cannot use UDP 1194 in two places.

If you have another OpenVPN service using that port, you must use a second IP address. This means probably taking your current primary address, making it an alias and giving Untangle a new primary WAN IP address. This frees you to convert the port forward used for the other OpenVPN to destination address, instead of destined local, maintaining it on the address it's already using, and moving Untangle to the new IP address for its use.

There is no other supported solution.

I removed the NAT/PAT records for port 1194 from the Untangle pointing to Ooma and reinstalled OpenVPN. Setup OpenVPN transferred .opvn file to laptop. Created hotspot on my mobile phone LTE connection. Fired up OpenVPN and connected. Unfortunately was unable to browse LAN nor able to get the correct public IP while using OpenVPN connection. Checked network settings and the TAP device showed IPv4 Connectivity: No network access. Will be researching why.

 

[Sky-Knight]

@gpg, test with IPs not names. DNS resolution is its own thing. Be aware that OpenVPN users are in their own address pool, a separate IP network from everything else. That means if you're testing against Windows stuff, the Windows firewalls on the devices behind Untangle are in the way. Which is why the NAT box is enabled by default for OpenVPN, I hate that option myself I much prefer to put the address pool into sites and services so those machines are on the domain. NAT is evil... I hate it.

Second, your egress IP won't change unless you tell Untangle to do full tunnel in the OpenVPN group, and then redistribute the client.

 

[gpg]

@gpg, test with IPs not names. DNS resolution is its own thing. Be aware that OpenVPN users are in their own address pool, a separate IP network from everything else. That means if you're testing against Windows stuff, the Windows firewalls on the devices behind Untangle are in the way. Which is why the NAT box is enabled by default for OpenVPN, I hate that option myself I much prefer to put the address pool into sites and services so those machines are on the domain. NAT is evil... I hate it.

Second, your egress IP won't change unless you tell Untangle to do full tunnel in the OpenVPN group, and then redistribute the client.

Thanks for your help appreciate it. Changed to full tunnel and got the correct IP.

 

[gpg]

Thanks all for your help! One other question, what GUI client do you recommend for Mac? I have many Mac users that will need a GUI to use rather than messing with a terminal? I have installed Tunnelblick and tested. Find it fairly easy to use. It had a DNS issue so I added OpenDNS IP to the WiFi settings on my Mac and all was good.

 

[YeOldeStonecat]

Thanks all for your help! One other question, what GUI client do you recommend for Mac? I have many Mac users that will need a GUI to use rather than messing with a terminal? I have installed Tunnelblick and tested. Find it fairly easy to use. It had a DNS issue so I added OpenDNS IP to the WiFi settings on my Mac and all was good.

I've noticed that with Tunnelblick on Macs...DNS issues..it's slow to pickup, slow to work. Sometimes it appears there is no connection to the internet..but wait several minutes and it will start working. Ugh.

 

[Sky-Knight]

Yeah, Tunnelblick is the best I know of on the Mac side. All of this is only made more annoying when you realize that OpenVPN on Untangle itself has been through some migratory stuff that's all but invisible.

Older installs will whine about deprecated certificates, if you see that you need to remove the module and start over to fix it. You can't import / export, or it'll just move the problem.

Then in the last two releases there have been changes in the comp-lzo directive on the server, changed to compress, then to compress lz4. Now you can see these directives on the advanced tab of OpenVPN. The rub is, they need to MATCH on the client and the server, so updating the configuration manually is trivial. BUT, if you change the server configuration, the client's need redistributed, or the .ovpn file manually modified to reflect the same change or the compression dies which kills the tunnel.

And if that wasn't enough of a twist... one could on the server use these directives:

compress lz4
push "compress lz4"

That tells the server to use lz4 compression, and to push lz4 compression to any client that connects neatly removing any compression directive requirement on the client at all! Yay! Oh wait... android and iOS OpenVPN clients won't receive push configurations until AFTER the tunnel stands up which is too late. Windows clients work fine, Tunnelblick works fine... mobile clients... splat....

So both client and server get compress lz4, older installations have comp-lzo, which can be directly replaced with compress lzo, and no client changes are needed. But you're still using the older, weaker compression that has some vulnerabilities associated with it.

OpenVPN on Untangle... absolutely wonderful, right up until it's a train wreck, just like most heavily automated things.