The folks at Untangle have released version 9.3 with some exciting changes. They have added a few features that I have been waiting for. First on the list is full tunneling. Something I have been looking for quite some time. The second big feature for me is the new SSD support. It does not support trim but they have optimize the way they write data to minimize write I/O’s making it suitable for an SSD. Below is a list of all the new features. If you are an existing user you will be upgraded but if you were on the fence, this may be worth looking at. Look for a future review on some of these features.
Download Software from here: http://www.untangle.com/
9.3 contains many platform and application improvements. It also has infrastructal changes to simplify settings and improve performance.
- Upgraded to ExtJS 4.0 (from ExtJS 2.2)
- Added Session graphs to faceplates
- Added more metrics to faceplate metrics list
- Improved session viewer with filtering, grouping, and additional fields
- Removed “Block page” skin settings – it now uses the main skin setting.
- New UI.
- Policy Manager rules now use rule builder.
- Full tunnel now supported. Simply enable “Full Tunnel” in the address pool of the clients/sites you wish to use full tunnel mode.
- You can now export any and all IPs (including WAN IPs)
- “Full tunnel” traffic will be scanned by the other apps as it traverses untangle so those users will get Web Filtering etc.
- Intermediate “events” schema removed
- Incremental reports process removed
- Event log queries now have no delay
- Removed “Full Refresh” button in event logs (Refresh is a full refresh now)
Kaspersky Virus Blocker
- Officially End-of-Life.
- On upgrade it will be removed.
- “Virus Blocker” replaces it.
The “Administration” regarding HTTPS/HTTP access settings have been simplified. HTTPS is no longer open/closed based on other settings, there is simply a setting that controls whether it is open or closed. The HTTPS port settings are now global. Previously when the HTTPS port setting was changed it only changed it on certain interfaces and kept it at 443 on other interfaces. This was not intuitive behavior and it interfered with port forwards. Be aware if you have changed the HTTPS port you will only be able to administer untangle through the HTTPS port you specified – not 443!
Limiting Administration to IP range
This functionality has been removed from config->administration because it is redundant. All it did was add packet filter rules to limit 443 access on WAN interfaces to the specified IP range. You can now accomplish the same thing by just adding those rules directly to config->networking->advanced->packet filter. Add one rule to block port 443 (or your admin port) access on the WAN interface(s). Then add one rule above that allowing access to port 443 on your WAN interface(s) from the desired IP range.
The settings for which reports to generate on which day have been simplified. The daily, weekly, and monthly schedules are now just checkboxes and you can check the days you want each generated. These settings are not 1:1 with the old settings so the conversion will keep your settings as close as possible to the original.
In reports, you can add users that do not have administration privileges but do have access to reports. Depending on when you setup these accounts you may need to re-enter the password for these users on upgrade.
All settings are now stored in files in /usr/share/untangle/settings/* instead of the database. This is part of an ongoing effort to simplify Untangle and also paves the way for more centralized management of Untangle settings for those users with many Untangle instances under management.
For power users settings can easily be copied or edited in /usr/share/untangle/settings/.
This also allows us to remove the database dependency from all of Untangle except the Reports application. This paves the way for having the database stored on an alternate server or a server in the cloud. This scenario can be better for large sites with large storage needs for events or for small sites with tiny boxes with no hard drive.
Hibernate and Events schema
The intermediate “events” schema has been removed. Events are now written directly to de-normalized tables in the “reports” schema. This means there is no incremental reports process that runs every few minutes to shuffle events out of the intermediate schema. This should significantly reduce the disk i/o requirements on large sites and also remove the delay from event logs.
Hibernate (the java persistence library) has also been removed. Events are now written using SQL directly to the reports schema. Event logs are now queried using SQL. This simplifies the code.