9.4.0 Changelog

Overview

9.4 has a new Captive Portal and several other architectural changes. There are also some minor feature enhancements and bugfixes.

Platform

• New Icons
• New Host Table (described below in detail)
• Improved Session Viewer (described below in detail)
• New Rules and Rule Conditions (described below in detail).
• Added new UI alerts for hard Drive full.
• Added new UI alerts for Untangle connectivity to datacenter.
• Fixes to password reset for older servers.
• Fixes foreign characters not always saving correctly to file.

Captive Portal

• New implementation (described below in detail)

Firewall

• "log" was renamed "flag" to be consistent with Web Filter and other apps. (Plus all sessions are logged so "log" is not accurate)
• A event log view to view all scanned sessions was added.

Other

• Tons of bugfixes

Architectural Changes

Captive Portal

Captive Portal receives an entirely new implementation in v9.4. This was done for several reasons. We see Captive Portal's role in Untangle's offering growing more important in several key markets, like schools, businesses and hotels, and the new Captive Portal has some important new features and functionality yet is also simpler and more maintainable.

The new Captive Portal is different enough that no conversion on upgrade was possible. As such, users of the 9.3 and prior Captive Portal will actually have to remove it from the rack in order to upgrade to 9.4. Once on v9.4 they can install and configure the new Captive Portal.

The big difference in the new Captive Portal is that it now exists in the "top" of the rack with the other filtering apps. This means you can have different Captive Portals (or no Captive Portal) on different racks that accomplish different tasks. This allows for some great use cases that have been frequently requested:

• Show a different captive portal to wireless users than wired users.
• Only show a captive portal page if the user is not already known via some other method (like the Active Directory Login Script).
• Show a warn captive page when the user goes over-quota or is added to the penalty box for bad behavior.
• Have special captive pages for specific sites.
• Have captive pages only for certain operating system and/or device types.
• Many more!

The other major difference is that the rules are now of the matcher/action format like other rules in Untangle. This combined with some new matcher types give the Captive Portal much more powerful rules that can accomplish different use cases.

Also, the custom captive page format has been changed to a python based system. We believe the new format will make both visual customization and functional customization of captive pages easier.

Captive Portal is now a regular app like the other apps in the rack and now makes no kernel level changes, which makes its operation more intuitive and consistent with other applications.

Host Table

In v9.4 there is now a global "table" that tracks local hosts and information about local hosts. Previously, the different apps would each separately store various bits of state about hosts on the network. For example, Directory Connector would maintain a list of mapping between hosts and their associated usernames.

In v9.4 this is now a part of the platform and is viewable by selecting "View Hosts" at the dropdown at the top of the rack. Some examples of things now stored in the host table:

• the host's associated username
• the host's associated hostname
• If the host is in the penalty box (and associated details)
• the host's quota (and associated details)
• some of the host's information (OS type, etc)

This has several larger implications. This information is now global and globally accessible by other apps. For example, the "Penalty Box" is now global (instead of each Bandwidth Control having its own) and other apps can now make rules based on the penalty box. This also makes it much easier to visualize what information is known about a host at any given time.

We've also added a periodic tasks that runs in the background and does reverse DNS lookups to attempt to determine the hostname for hosts that don't already have a known hostname.

Session Viewer

The Session Viewer received major improvements. Its much much faster and now paginated when sessions > 1000 so that large servers don't hang when viewing sessions. It now has the ability to filter based on values provided by the users. All the grouping/filtering/column selections has been moved to the dropdown at the top of the column and the session selection is now in a dropdown at the bottom. This makes the page significantly clearer and easier to view in lower resolutions.

Rules

9.4 completes Untangle's move to the new rule format. Long time users of Untangle will remember the table based rules had extremely wide tables with lots of columns, which most columns were usually "any" and then there was finally an action to perform if the rule matched.

The new rules specify a list of "matchers" which are attributes that should determine if the rule matches and then an action to perform if the rule matches. All application rules are now of this format.

Rules that match at session creation time:

• Firewall
• Policy Manager
• Captive Portal

Rules that match deeper in the session:

• Application Control
• Bandwidth Control

We've also added several new matcher types:

• Client Hostname
• Client in Penalty Box
• Server in Penalty Box
• Client has no Quota
• Server has no Quota
• Client has exceeded Quota
• Server has exceeded Quota
• HTTP: Client User Agent
• HTTP: Client User OS

Some new deep session matchers:

• HTTP: Hostname
• HTTP: Content Type
• HTTP: Content Length

These new matchers allow for some powerful new configurations. One of the most requested is the ability to create different racks for different OS types, like iPads or mobile devices based on the HTTP User Agent string.

Bandwidth Control

Bandwidth Control received some new default rulesets suggested by the wizard. On upgrade from previous versions your ruleset will not be changed, but if you would like the new defaults simply re-run the wizard and choose the profile that best describes your organization.

The defaults were changed based on feedback from the field. The 9.3 and prior rules often had rules deprioritizing HTTP to unproductive sites to Low priority (like Social Networking in schools). By default the Low priority receives between 6% and up to 100% of your bandwidth assuming no higher priorities request it. On smaller sites Low usually receives a fairly high amount of bandwidth because there is not always a lot of bandwidth consumed by the higher priorities. However, on large sites where this is a large amount of traffic in each priority, this results in the Low priority receiving bandwidth close to its lower bound (6-10%).

De-prioritizing "unimportant" web traffic seems like a good idea, however the web is very complex. For example, when visiting a new site often content is loaded from other sites like Facebook for integrated Facebook login or to allow commenting on articles. This means that the Facebook content would be downloaded at a Low priority, but as a result the entire news page would render slowly despite the news site itself being a high priority. Since most people judge the internet speed by the render time of the web browser, this would sometimes result in a user complaints about the web being slow, when in actuality it was just web traffic being deprioritized over other traffic as configured.

As such, we've changed approach to always prioritize port 80 traffic at the Medium level or higher. The problem with this approach is that large web downloads or streaming port 80 traffic will receive that same priority which is obviously not latency sensitive content. To combat this, we've added a "HTTP: Content Length" matcher which allows large downloads to be prioritized lower while actual interactive web content is prioritized highly. Similarly, "HTTP: Content Type" can be used to deprioritize any specific content types that should not receive a high priority.

We think this will provide a better web experience on the whole. As explained this is just the default suggested approach. Users are free to configure whatever rules they think are best for their network and their use case.