Tangling with Untangle

Posted: October 18th, 2010 | Author: | Filed under: computing | Tags: , | 8 Comments »

This is a work in progress as I build up an Untangle box for personal use. Using the Lite (open source) version 7.4 (EDIT 11.15.2010 -- now running 8.0.0) on a Xeon server with 4 physical interfaces.

DO NOT follow any of this verbatim. This is a jumble of notes for my personal use that I hope may help a few other folks trying for a similar setup.

Install from USB disk: http://wiki.untangle.com/index.php/Installing_Untangle_from_a_USB_Flash_Disk
Use manual partitioning to setup full disk encryption (sda2_crypt) with LVM for separate / and /home. ext2 /boot, xfs for root & home

Enable & lockdown ssh:
* edit /etc/ssh/sshd.conf with my preferred config
* mv /etc/ssh/sshd_not_to_be_run /etc/ssh/sshd_not_to_be_run.bak
* restart ssh

Use the terminal from the gui to create root password and a non-root user
Lockdown ssh from root login and setup key login for non-root user (disable direct root login and restrict to specific user account using AllowUsers, also enable MaxStartups 10:30:60).

Add USB key for LUKS

Install GRUB password and backup menu.lst against future Untangle updates
Add grub boot option for verbose, non-splash boot and make default selection
# altoptions=(text boot) vga=791
Add /boot/grub/menu.lst as a file override in the gui.

/etc/default/bootlogd change BOOTLOGD_ENABLE=Yes

Edit /etc/apt/sources.list to uncomment debian main. (re-comment and apt-get update when done installing)

Install xfsprogs
Install/configure smartmontools
Install mlocate
Install memtest86+
Install/configure lm-sensors & i2c-tools

Secure the Untangle kiosk (X does not belong on servers but Untangle depends on it.. oh well.)
Instructions for locking down physical access to the Untangle kiosk:

First, follow jdelagarza’s excellent post on setting up xscreensaver and test that it’s working:

Unfortunately this can still be easily defeated using ctrl+alt key combos to restart X.
1) build a good xorg.conf (see example below) so Xserver uses /etc/X11/xorg.conf instead of falling back to /etc/X11/xorg-untangle-vesa.conf (which is useless to modify directly as it automatically overwritten by /home/kiosk/.bashrc)

2) add a ServerFlags section with the following options:
“DontZap” to disable ctrl+alt+bksp and ctrl+alt+del
“DontVTSwitch” to disable ctrl+alt+F[1-12] (especially want to disable F10 which also kills X)
“DontZoom” to disable using ctrl+alt+[+/-] to crash X

3) reboot/restart X
My current /etc/X11/xorg.conf

# xorg.conf (X.Org X Window System server configuration file)
# If you have edited this file but would like it to be automatically updated
# again, run the following command:
# sudo dpkg-reconfigure -phigh xserver-xorg

Section "ServerFlags"
Option "DontZap" "true"
Option "DontVTSwitch" "true"
Option "DontZoom" "true"

Section "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "pc104"
Option "XkbLayout" "us"

Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"

Section "Device"
Identifier "Configured Video Device"
Driver "vesa"

Section "Monitor"
Identifier "Configured Monitor"
VertRefresh 60

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
DefaultDepth 24
SubSection "Display"
Depth 24
Virtual 1024 768
Modes "1024x768"

You can verify which xorg.conf file the Xserver is using with this command:
# cat /var/log/Xorg.0.log | grep “Using config file”

See this forum post for comments: http://forums.untangle.com/hacks/19035-secure-kiosk-locking-down-xscreensaver.html

Reconfiguring packet filter to allow DHCP on other interfaces

Hmmm.. trying to research how to serve DHCP on interfaces other than the Internal and DMZ but still be able to use packet filter to block unwanted interfaces. The following post explains how we can config dnsmasq to serve on multiple interfaces but the only suggestion for configuring the packet filter is to turn off DHCP filtering for all interfaces, which leaves the External interface exposed:

I didn’t like this, and after a bit of searching it appears I’m not alone:

So.. as a long time linux user it seemed only proper to crack open my Untagle box and do a bit of digging.

It appears that the following ruby script is responsible for doing most the work of translating the packet filter gui into actual iptables rules:


When you apply changes in the gui the script then rebuilds the iptables rules in this file:


By studying this file you can see that when you apply the built-in “Allow DHCP Requests from the internal interface.” rule it creates the following iptables rule:

iptables -t filter -I INPUT 1 -p udp -m mark --mark 2/2 -m multiport --destination-ports 67 -j RETURN

The “Allow DMZ..” rule does the same except that the “--mark 2/2” portion changes for each interface.

I then tried making an “Allow DHCP” rule of my own for my eth3 using the gui which creates this actual iptable rule:

iptables -t mangle -A firewall-rules -p udp -m multiport --destination-ports 67 -m mark --mark 8/8 -j RETURN

Now we’re onto something… I then checked the “Block all DHCP Requests to the local DHCP Server.” rule and found it creates:

iptables -t filter -A INPUT -p udp -m multiport --destination-port 67 -j DROP

Bingo! The difference is that all the user rules are created by appending rules to the end of “firewall-rules” rule set of the “mangle” table whereas the built-in set of Allow rules are inserting rules into the top of the input chain (INPUT 1) in the default “filter” table. In short this means that when creating custom user rules they’re getting added after the the built-in “Block all DHCP..” rule so the DHCP packets are being dropped before they ever get to the user created Allow rules (vs the built-in Allow rules that get inserted before the built-in “Block all DHCP..” rule).

I was able to test this by manually adding an iptable rule for my eth3 interface that uses the insert vs the append method and it was successful in allowing DHCP (but this would get overwritten by untangle in the next rule refresh):

iptables -t filter -I INPUT 1 -p udp -m mark --mark 8/8 -m multiport --destination-ports 67 -j RETURN

So.. now understanding the issue. The simplest solution I found was to just abandon the built-in rules and do it all through a couple user rules.

1) Uncheck: “Block all DHCP Requests to the local DHCP Server.”, “Allow DHCP Requests from the DMZ interface.”, “Allow DHCP Requests from the internal interface.”

2) Create a user rule to accept on any of the interfaces you do want DCHP:
Action: Pass, Protocol: UDP, Destination Port: 67, Source Interface: Internal, eth3

3) Create a rule to Drop on all the interfaces:
Action: Drop, Protocol: UDP, Destination Port: 67, Source Interface: all (even the ones you checked in the previous Pass rule)

Make sure the Pass rule is ordered above the Drop rule. Assuming your DHCP is configured correctly you should now have DHCP access on any interfaces you have checked within the Pass rule.

Mapping the Untangle Packet Filter rules.

The interfaces on this box are identified by Untangle as follows ( the “--mark #/#” is basically another identifier for the different interfaces within iptables):
eth0 = External (--mark 1/1)
eth1 = Internal (--mark 2/2 and --mark 258/258)
eth2 = DMZ (--mark 4/4)
eth3 = eth3 (--mark 8/8)
VPN (--mark 128/128)
All Interfaces (--mark 256/256)

First line = the built-in rule description listed in the Untangle gui.
Second/third lines = actual rule(s) created in /etc/untangle-net-alpaca/iptables-rules.d/400-firewall by checking the gui description.


Allow DHCP Requests from the internal interface.
${IPTABLES} -t filter -I INPUT 1 -p udp -m mark --mark 2/2 -m multiport --destination-ports 67 -j RETURN

Allow DHCP Requests from the DMZ interface.
${IPTABLES} -t filter -I INPUT 1 -p udp -m mark --mark 4/4 -m multiport --destination-ports 67 -j RETURN

Block all DHCP Requests to the local DHCP Server.
${IPTABLES} -t filter -A INPUT -p udp -m multiport --destination-port 67 -j DROP

Prefer Local DHCP Traffic from non-internal interfaces.
${IPTABLES} -t mangle -A FORWARD -p udp -m multiport --destination-ports 67,68 -m physdev --physdev-is-bridged --physdev-out eth1 -j DROP
${IPTABLES} -t mangle -A FORWARD -p udp -m multiport --destination-ports 67,68 -m physdev --physdev-is-bridged --physdev-in eth1 -j DROP

Accept DHCP traffic to the local DHCP client.
${IPTABLES} -t filter -I INPUT 1 -p udp -m multiport --destination-ports 68 -j RETURN

Accept DNS traffic from the Internal and VPN interfaces to the local DNS Server.
${IPTABLES} -t mangle -A firewall-rules -p udp -m multiport --destination-ports 53 -m mark --mark 258/258 -j RETURN
${IPTABLES} -t mangle -A firewall-rules -p udp -m multiport --destination-ports 53 -m mark --mark 384/384 -j RETURN

Accept DNS traffic to the local DNS Server from all interfaces.
${IPTABLES} -t mangle -A firewall-rules -p udp -m multiport --destination-ports 53 -m mark --mark 256/256 -j RETURN

Accept SNMP traffic from the Internal interface.
${IPTABLES} -t mangle -A firewall-rules -p udp -m multiport --destination-ports 161 -m mark --mark 258/258 -j RETURN

Accept SNMP traffic from all interfaces.
${IPTABLES} -t mangle -A firewall-rules -p udp -m multiport --destination-ports 161 -m mark --mark 256/256 -j RETURN

Block OpenVPN traffic from the internal interface.
${IPTABLES} -t mangle -A firewall-rules -p udp -m multiport --destination-ports 1194 -m mark --mark 258/258 -j alpaca-pfi-drop

Accept OpenVPN traffic from all interfaces.
${IPTABLES} -t mangle -A firewall-rules -p udp -m multiport --destination-ports 1194 -m mark --mark 256/256 -j RETURN

Accept SSH traffic from all interfaces.
${IPTABLES} -t mangle -A firewall-rules -p tcp -m multiport --destination-ports 22 -m mark --mark 256/256 -j RETURN

Allow Ping on all interfaces.
${IPTABLES} -t mangle -A firewall-rules -p icmp -m mark --mark 256/256 -j RETURN

Block all local traffic.
(added to 700-nat-firewall)
${IPTABLES} -t mangle -A firewall-rules -j alpaca-pfi-drop

Accept incoming VPN traffic when running as a VPN client.

Route VPN traffic that would go through the Bridge.

Samba + SWAT + GOsa setup:
# apt-get install samba=2:3.2.5-4lenny11 samba-common=2:3.2.5-4lenny11
# apt-get install swat smbfs samba-docs
Create separate Packet Filter rules to allow 135,139,445 TCP and 137,138 UDP from select interfaces
Setup via SWAT (localhost 901)

uncomment apt deb sources and add deb unstable
# apt-get install gosa (to install dependent packages)
# apt-get install -t unstable (to install newest gosa with fcgi bug fix)
# apt-get install gosa-schema gosa-plugin-ldapmanager gosa-plugin-samba smbldap-tools libnss-ldap libpam-ldap
# apt-get remove lighttpd (conflicts with apache2)

Use /usr/share/doc/gosa/slapd.conf-example/slapd.conf.gz for /etc/ldap/slapd.conf and customize

pulling gosa off and using webmin instead.
# add webmin repo
deb http://download.webmin.com/download/repository sarge contrib

Other good references:

Untangle -- useful files:

* Configure untangle modules
* Add LUKS disk encryption for second SATA drive and for external eSATA backup drives
* Setup filesharing via Samba
* OpenVPN
* Bootp
* Enable sadc in /etc/default/sysstat ?

*** This post is still under construction ***

8 Comments on “Tangling with Untangle”

  1. 1 James said at 9:26 pm on November 2nd, 2010:

    Great article, this is something that I spent hours trying to get to work. All of the so called experts on the forums don’t want to actually answer questions. Your explanation was very complete and easily understood. I am setting up an untangle server to segment my home network into three different subnets. Ended up using static IP addresses on some subnets. I will go back and try to fix those with static DHCP reservations now.

    Still don’t quite understand the difference between packet filters and firewall rules. It would be very useful if there were diagrams showing how data flows through an untangle server and where the various components interact in the data flow.

  2. 2 admin said at 12:23 am on November 3rd, 2010:

    Glad it helped. As far as I can tell the Packet Filter is just an iptables gui whereas the UT Firewall module exists within the UVM. Since iptables is running at the kernel level I would guess that it receives incoming packets first, filters them according to the packet filter rules and then passes all the remaining traffic on to the UVM where it is evaluated and logged by the Firewall or other modules. The Untangle design is that you should use the Packet Filter for filtering traffic destined for the UT box itself and use the Firewall for traffic between networks. You could do a lot more with Packet Filter, but unfortunately they’ve crippled it by disabling iptables logging and if you try to manually add rules outside of the gui they’ll just get overwritten as UT appears to periodically refresh the ruleset. When time allows I’m hoping to find a workaround to enable the iptables logs that doesn’t involve having to hack up the ruby file that runs the Packet Filter gui.

  3. 3 Theo Boomsma said at 10:52 am on March 13th, 2011:

    Hi there

    Absolutely great article as I am also hacking into the basic Untangle infrastructure. We still want to use it for the GUI but whenever we need to so something extra it is nice to get into the Linux nitty gritty.
    Just wanted to ask if you’ve been able to solve the OpenVPN hack. I’m facing big problems with openVPN clients and Site-2-Site setup. They login fine .. ping the server IF’s great but absolutely cannot go beyond these IF’s even when setting the Exported Networks in UT. I know now where the IPTables scripts are created from but cannot figure out where to look for OpenVPN rules.

    Any advice is welcome

  4. 4 admin said at 12:01 pm on May 16th, 2011:

    Theo – sorry for the long delay in seeing your comment. Unfortunately I’m haven’t played with the UT OpenVPN functionality (I have a Cisco box handling VPN) so I’m not going to be much help. Let me know if you figured it out.

  5. 5 admin said at 12:12 pm on May 16th, 2011:

    @ Theo – also, have you tried toggling the “Route VPN traffic that would go through the Bridge.” rule in the Packet Filter settings?

  6. 6 Theo Boomsma said at 5:59 am on May 17th, 2011:

    Hi .. thanks for the reply

    I did manage to get openVPN up and running … it was a routing (or route-back) issue. The untangle-testmachine was NOT my network’s default GW and servers weren’t returning routed packages back to the proper GW2.
    I fiddled around installing Webmin in the UT box and getting more grip on modules but every time you change something in the UT GUI settings were overwritten again.
    I decided to move on to BSD based pfSense 2.0 and that is in my opinion superb in every sense. It supports multiple wan’s with more than one GW(per WAN) and is completely FREE .. uses on my ESXi only 2Gb diskspace & 700Mb RAM yet it outperforms Untangle by far…


  7. 7 admin said at 3:43 pm on May 17th, 2011:

    @ Theo – Glad to hear you got OpenVPN running.

    Thanks for sharing about pfsense. I had looked at that briefly but chose Untangle for the web GUI. I’m comfortable in CLI but have found that my laziness is overcoming the purist in me. I’ve grown tired of having to dust off my IOS skills every time I want to make a quick change on my Cisco routers and liked the idea of a mind-numbingly simple gui for doing quick configs and reviewing logs (it’s finally spring in the mountains and I’d rather be on the mountainbike or moto). Are you using a gui with pfsense? If so, is it as robust as Untangle for basic admin chores?

  8. 8 Burhan uddin said at 7:02 am on February 20th, 2013:

    Hello i am new to Linux and untangle my Web filter and Web cache Expire can any body Help me please i shall be very thankfull to you please if any one know reply on my nEmail


Leave a Reply