13.0.0 Changelog

Overview

13.0 is a major new release. It contains a new administration interface and major new functionality.

The new administrators interface

At Untangle, we're all about making an elegent and simple solution. Networking is hard and complicated, and making it "easy" can be difficult. We're always trying to innovate to make things easier and more intuitive. While the old administrator interface was great, and the best in the industry in our opinions, we found that we needed to rethink some things in order to continue to innovate.

To address this we reimplemented the UI using the newest extjs library in a true MVC architecture. This will provide a better platform to continue to innovate.

There are already some big improvements that will benefit everyday administrators of Untangle:

The new UI loads faster, renders faster, and is quicker to respond.

Untangle now uses "URL Routing" has a few benefits. Access parts of the interface directly (like https://IP/admin/index#/config/about). You can now use the back button like a regular web application. For example, In Apps you can click on "Web Filter" and then click "back" to go back to Apps.

Rule building is essential to configuring Untangle. The new rule builder should be faster and easier.

The dashboard and charts and customized reporting are now cleaner and simpler.

The new default skin is no longer the "rack" but the simplified view. The old "rack" will still be available via the skin, but the new default will be the "simple" skin for a cleaner more modern look and feel.

There are dozens and dozens of major improvements that the new architecture now enables.

Bufferbloat

Untangle has new queueing algorithms to eliminate bufferbloat. Bufferbloat is poor latency caused by excess buffering in networking equipment.

Untangle now supports a queueing algorithm (fq_codel) that can be combined with intelligent prioritization of Bandwidth Control and QoS to ensure good performance even when your connection is under significant load.

The Bufferbloat page has more information about how this works.

User Tracking

Untangle has 3 major tables. Sessions, Hosts (IP addresses), and Devices (MAC addresses). These tables store information about the various entities on the network. Untangle now adds a "User" table that can store information about the various usernames in use on the network.

This enables things like user-based quotas, and user tagging.

Tags

Previously, Untangle had the concept of the "Penalty Box." Certain hosts could be "penalty boxed" when they did something that violated network policy. Penalty boxing is now implemented in an abstract sense with "tagging." You can now tag hosts, devices, and users with certain string tags which are just strings that can serve any purpose. To penalty box a device, just tag the device with "penalty-box" and all that device's traffic will now be associated with that tag.

Now you can specify any tag for any purpose. A couple examples:

You can tag all student devices with "student" or "kid" to more easily use policy manager to send "student" tagged traffic to a student rack. You can tag bittorrent users os "bittorrent" so you can treat them differently. You can tag hosts that are behaving suspiciously like opening many RDP connections quickly as "suspicious." You can tag users that are over quota as "exceeded-quota."

Tags provide an easy way to keep track of host/device/user status and use rules to check tags and handle accordingly.

Triggers

Trigger rules a new feature that allows administrators tag hosts, devices, or users when certain events occur. Trigger rules, similar to alert rules, are evaluated on all "events" and can be configured to tag or untag entites on virtually any event.

A couple examples: A user uses a certain application like a "proxy" application tag them as a "proxy-user". A device logs into a certain website, like a teacher portal, as "teacher" so they can handled accordingly.

Alerts

Alert rules have been simplified to make creation of custom alert rules much easier. Now the administrator can choose the specific event they would like to alert on, and then set the conditions fields based on the attributes available within that specific event.

Alerts have also been removed from Reports and moved into the "platfrom" in Config > Events

Syslog

Syslog has been reimplemented using rules. Previously, enabling syslog enabled the sending of ALL events, encoded in JSON, to syslog server. While, in theory, this works as the syslog server had access to all events, in reality this was like trying to sip from the fire hose. Untangle logs a huge number of events and syslogging all events was a big performance penalty.

Now syslog uses rules just like alert rules or trigger rules where the administrator can specify which events should be sent to the syslog server. This could range anywhere from very specific occassional events to all events just like the old events.

OpenVPN Advanced

Untangle's OpenVPN implementation strives to be simple and elegant. Those desiring very advanced or specific openvpn configurations can always run their own openvpn configurations on their own server, and for those wanting a simple openvpn deployment can use Untangle.

However, there are many times when users want the simplicity of the Untangle implementation, but only one or two changes. Unfortunately, with a wide array of users, each user has varying opinions of which settings should be exposed.

In order to continue to meet our design goals and keep things simple, but enabling very advanced users to manage the settings explicitly, we added an "Advanced" tab. The "Advanced" tab allows administrators to override the way untangle writes the openvpn configuration, or append their own settings.

This allows advanced users to tweak their openvpn configuration very similar to how they would edit the config file, but still maintain the benefit of the Untangle implementation.

Beware, usage of the "Advanced" tab in OpenVPN is NOT support by the Untangle support team. For admins wishing to tweak and customize their openvpn attributes, they must be prepared to read the OpenVPN documentation and expermient and troubleshoot.

Captive Portal

You can now change captive portal to use MAC address as the primary key when available. If "Track logins using MAC address" is enabled, Captive Portal will use MAC address. If no MAC address is known for a given host it will continue to use the IP address.

Turris Omnia

Untangle now officially support the "Turris Omnia" open source router. Similar to other firmwares - you can flash your Turris Omnia with a fully functional Untangle.

Wireless

802.11ac is now supported. Wireless card "capabilities" are now automatically detected and the appropriate speed & capabilities are used.

Other minor improvements

• OpenVPN moved to 2.4.0 (thanks WebFool!)
• Host and device table cleanup logic improved to prevent stale entries from polluting reports
• Device table now has an explicity field for username and hostname set by the admin
• Web Filter Lite has officially been removed and will disappear on upgrade