UTM as VPN "Client"

Correct and because Sophos does not want it to be done.  I've detailed the various business/marketing reasons for this in several previous threads, so no need to rehash here.  Although offered for free home use, ALL design decisions on the UTM are specifically catered to business usage for paid business users and this particular "feature" has some very real potential negative connotations that Sophos is keenly aware of.  If this is a make or break for you, there are several home centric gateway products that have this capability, which you could setup upstream of the UTM.

I would assume if the openvpn script(s) running on the backend were edited, this would allow UTM to function as a client, right?

[SIZE="1"]**DISCLAIMER: Making any changes via the command line interface [cli] results in the loss of support and warranty for paid licensees**[/SIZE]

Found OpenVPN backend script:

/var/mdw/scripts/openvpn

#!/bin/sh
#
# Copyright (C) 2015 Sophos Inc.
# For copyright information look at /doc/astaro-license.txt
# or http://www.astaro.com/doc/astaro-license.txt
#
# Maintainer: Heiko Hund 
#

CHROOT='/var/sec/chroot-openvpn'
OPENVPN='/usr/sbin/openvpn'
STARTPROC='/sbin/startproc'
KILLPROC='/sbin/killproc'
CHECKPROC='/sbin/checkproc'
TOUCH='/usr/bin/touch'
RM='/bin/rm'
GREP='/usr/bin/grep'
MOUNT='/bin/mount'
PERL='/usr/bin/perl'

NOSELFM='/etc/no-selfmonitor/openvpn'

test -x ${CHROOT}${OPENVPN} || exit 5

. /etc/rc.status

rc_reset

SERVICE='OpenVPN'
PID_FILE='/var/run/openvpn.pid'
CFG_DIR='/etc/openvpn'
CFG_FILE="$CFG_DIR/openvpn.conf"

# Make sure proc is mounted in chroot
$GREP ${CHROOT}/proc /proc/mounts >/dev/null 2>&1
if [ $? == 1 ] && [ $1 == 'start' ]; then
    $MOUNT -t proc proc ${CHROOT}/proc >/dev/null 2>&1 || rc_exit
fi

# Check if a client connection reference was given
if [ -n "$2" ] && [ "${2:0:4}" = 'REF_' ]; then
    SERVICE="OpenVPN client connection $2 "
    PID_FILE="/var/run/openvpn-client-${2}.pid"
    CFG_FILE="/etc/openvpn/client/${2}/config"
fi

case "$1" in
    start)
        echo -n "Starting $SERVICE "
        OPTIONS="--config $CFG_FILE --writepid $PID_FILE"
        "$0" status "$2" >/dev/null ||
                $STARTPROC -f -W $CHROOT$PID_FILE -c $CHROOT $OPENVPN $OPTIONS
        $RM -f $NOSELFM
        rc_status -v
        ;;
    stop)
        echo -n "Shutting down $SERVICE "
        $TOUCH $NOSELFM
        $KILLPROC -p "${CHROOT}${PID_FILE}" -g -c $CHROOT -TERM $OPENVPN
        rc_status -v
        ;;
    force-stop)
        echo -n "Shutting down all OpenVPN instances "
        $TOUCH $NOSELFM
        for pid_file in ${CHROOT}/var/run/openvpn*.pid; do
            $KILLPROC -p "$pid_file" -c $CHROOT -TERM $OPENVPN
            if [ "$?" -ne 0 ]; then
                break
            fi
        done
        rc_status -v
        ;;
    try-restart)
        "$0" status "$2" >/dev/null &&  "$0" restart "$2"
        rc_status
        ;;
		    try-restart)
        "$0" status "$2" >/dev/null &&  "$0" restart "$2"
        rc_status
        ;;
    restart)
        "$0" stop "$2"
        "$0" start "$2"
        rc_status
        ;;
    force-reload)
        echo -n "Reloading $SERVICE "
        "$0" stop "$2"  &&  "$0" start "$2"
        rc_status
        ;;
    reload)
        ;;
    status)
        echo -n "Checking for $SERVICE "
        $CHECKPROC -k -p "${CHROOT}${PID_FILE}" -c $CHROOT $OPENVPN
        rc_status -v
        ;;
    dhgen)
        $PERL -we '
            use Fcntl qw(:flock);
            use POSIX qw(setsid nice);
            my $bits = shift || 2048;
            my $outdir = shift || "/tmp";
            sub error { print shift() . "\n"; exit 1; }
            error "Unsupported DH parameter size, must be 1024|2048|3072|4096"
                unless $bits =~ /^(1024|2048|3072|4096)$/;
            fork and exit;
            setsid;
            umask 0;
            chdir "/";
            my $lockfile = "/var/lock/ovpn_dhgen_$bits.lock";
            open my $lock_fh, ">$lockfile"
                or error "Could not open lockfile $lockfile: $!";
            error "Generation of local $bits bit DH parameters is already in progress"
                unless flock $lock_fh, LOCK_EX|LOCK_NB;
            print "Starting generation of local DH parameters ($bits bit) in background\n";
            nice 19;
            open STDIN, "/dev/null";
            open STDERR, ">/dev/null";
            system qq(/usr/bin/openssl dhparam -out "${outdir}/dh${bits}.local.pem" $bits)
        ' "$2" "${CHROOT}${CFG_DIR}"
        ;;
    *)
        echo "Usage: $0 {start|stop|force-stop|status|try-restart|restart|force-reload|reload|dhgen } [client connection]"
        exit 1
        ;;
esac

rc_exit

[SIZE="1"]The below statements won't work due to Sophos' implementation of confd, see this post[/SIZE]
I have some testing to do, however I would assume one could run multiple servers via creating a variable and inputting that variable into CFG_FILE="$CFG_DIR/$ConfigVariable"

I would also assume you could place a client config in place of the server config at: CFG_FILE="$CFG_DIR/openvpn.conf".  Additional editing of commands would still need to occur for a client setup

• Note CFG_FILE="/etc/openvpn/client/${2}/config"
  

[SIZE="1"]**DISCLAIMER: Making any changes via the command line interface [cli] results in the loss of support and warranty for paid licensees**[/SIZE]

Additionally:

/var/confd/res/openvpn/client.ovpn-default 

[]
client
dev tun
proto []
remote [] []
tls-remote "[]"
route remote_host 255.255.255.255 net_gateway
resolv-retry infinite
nobind
persist-key
persist-tun
ca []
cert []
key []
auth-user-pass
cipher []
auth []
comp-lzo []
route-delay 4
verb 3
reneg-sec 0

While I've mentioned the chroot directory before, here is:

/var/sec/chroot-openvpn/etc/openvpn/openvpn.conf-default

dev tun

proto []
local []
port []
mark 4458

daemon
multihome
server []

[]
cipher []
auth []
comp-lzo []

persist-key
persist-tun
reneg-sec []
keepalive 10 120
verb []
down-pre
username-as-common-name

capath /etc/openvpn/ca.d
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/[]

client-config-dir /etc/openvpn/conf.d
status /var/run/openvpn-status.log
ifconfig-pool-persist /var/run/ipp.txt

management /var/run/openvpn_mgmt unix
management-client-user root
management-client-group root

push dhcp-option NTP 129.6.15.30
tun-mtu 60000

plugin /usr/lib/openvpn/plugins/openvpn-plugin-utm.so

• Note: I added the NTP and tun-mtu
  

[SIZE="1"]**DISCLAIMER: Making any changes via the command line interface [cli] results in the loss of support and warranty for paid licensees**[/SIZE]

I'm not going to engage in an argument with someone who bases their beliefs on assumptions and not what the EULA actually says.

As a home user, you are not entitled to support... period.  At this point, I would encourage you to read the EULA, something you clearly have not done (I encourage paying specific attention to 15.6.3 and 15.7.2).

Don't get me wrong... I am not trying to argue at all. I am just trying to understand is all. As for the EULA, just because I read, came to an understanding, and agreed to it, doesn't mean I remember it. Thank you for pointing this out and making it so clear. I had misunderstood what the EULA and the warnings were getting to as a whole.

I have also found the files you mentioned, though the directory makes me curious:

/var/sec/chroot-openvpn/etc/openvpn/

Especially when the following ps command (and output):

# ps aux | grep -v grep | grep vpn

root     10679  0.0  0.0  36652  1480 ?        Sl   13:02   0:00 /usr/local/bin/reporter/vpn-reporter.pl

root     26157  0.0  0.0   5864  2332 ?        Ss   Oct15   0:19 /usr/sbin/openvpn --config /etc/openvpn/openvpn.conf --writepid /var/run/openvpn.pid

root     26159  0.0  0.0   5004   556 ?        S    Oct15   0:01 /usr/sbin/openvpn --config /etc/openvpn/openvpn.conf --writepid /var/run/openvpn.pid

So... If I understand how this would work correctly... All I would need to do is get my .ovpn config file (and certs) to the gateway, and start another openvpn process, using a command similar to the ps aux output, right?

I have also found the files you mentioned, though the directory makes me curious:

/var/sec/chroot-openvpn/etc/openvpn/

Especially when the following ps command (and output):

# ps aux | grep -v grep | grep vpn
root     10679  0.0  0.0  36652  1480 ?        Sl   13:02   0:00 /usr/local/bin/reporter/vpn-reporter.pl
root     26157  0.0  0.0   5864  2332 ?        Ss   Oct15   0:19 /usr/sbin/openvpn --config /etc/openvpn/openvpn.conf --writepid /var/run/openvpn.pid
root     26159  0.0  0.0   5004   556 ?        S    Oct15   0:01 /usr/sbin/openvpn --config /etc/openvpn/openvpn.conf --writepid /var/run/openvpn.pid

So... If I understand how this would work correctly... All I would need to do is get my .ovpn config file (and certs) to the gateway, and start another openvpn process, using a command similar to the ps aux output, right?

Whenever openvpn is run on a router/server, it's good practice to jail it; in doing so, if the vpn is ever compromised, the attacker will only be able to gain access to whatever is contained within the chroot jail (i.e. only what openvpn has access to).  While it's good practice, it's not always feasible to do so; for example, it causes more problems than it's worth on OpenWRT.

Normally, that's all it would take, however, after looking at the script, I don't think it's going to be quite that simple due to how Sophos has implemented OpenVPN [i.e. dynamically creating the configs and subsequently deleting them).  I only have basic knowledge of linux and scripting, so it's going to take me some time to trace commands and see what's what.  I was thinking it [openvpn script] should look similar to OpenWRT's OpenVPN script [not command wise, but path-wise), allowing a few simple edits, but I'm perplexed as to how it's dynamically creating confs and subsequently deleting them. 

The above assumes one wants to keep Sophos in complete control over the vpn via the web gui, as I would prefer it to be an integrated solution into the web gui.  If you don't care about the web gui integration, the script could be modified to simply run client/server configs and not involve other system processes which are needed for the web gui.  I don't have enough knowledge to do so, however it shouldn't be any different than how one would run openvpn in OpenWRT without the openvpn luci package. 

If you chose to go that route, you would need to configure individual firewall rules allowing access to and from the vpn (reference the rules in the OpenVPN Wiki I wrote for OpenWRT).  I also believe a vpn interface would probably need to be configured, not sure if Sophos also creates that dynamically.

Prior to editing anything or making changes to Sophos files, create a backup via the webgui, as well as a backup of each file you edit prior to editing (i.e. cp file.1 file.1.bak)

@BAlfson is also working on it and below is what he's emailed me thus far (I don't think he'd mind me sharing, so I apologize in advance for not asking first):

I found:

:/etc # /var/mdw/scripts/openvpn
Usage: /var/mdw/scripts/openvpn {start|stop|force-stop|status|try-restart|restart|force-reload|reload|dhgen } [client connection]

# ls /usr/local/bin/o*
/usr/local/bin/openvpn-client-status.pl
/usr/local/bin/openvpn_connections.sh
/usr/local/bin/openvpn-server-status.pl
/usr/local/bin/ovpnsh

So... If I understand how this would work correctly... All I would need to do is get my .ovpn config file (and certs) to the gateway, and start another openvpn process, using a command similar to the ps aux output, right?

I've never run a router as a client before, so I'm not sure if your client config would need to be a ovpn file or a conf file.  This should be fairly easy to find out though via OpenVPN's HowTO page. (I do remember discussing this with another user on OpenWRT's WRT1900ac thread, and if I can recall around what thread pages it was discussed, I'll take a look there as well [I've been following that thread since pg 103 and it's now in the 320's, so no guarantees]).

Also, I remember from the Sophos install stating if I didn't want the enterprise features, it would only be a basic linux OS... I think a good place to start may be checking out how the openvpn script is written for a linux distro.  I may not have time to do so tonight, but will tomorrow at the latest.

[SIZE="1"]**DISCLAIMER: Making any changes via the command line interface [cli] results in the loss of support and warranty for paid licensees**[/SIZE]

So... If I understand how this would work correctly... All I would need to do is get my .ovpn config file (and certs) to the gateway, and start another openvpn process, using a command similar to the ps aux output, right?

I've never run a router as a client before, so I'm not sure if your client config would need to be a ovpn file or a conf file.  This should be fairly easy to find out though via OpenVPN's HowTO page. (I do remember discussing this with another user on OpenWRT's WRT1900ac thread, and if I can recall around what thread pages it was discussed, I'll take a look there as well [I've been following that thread since pg 103 and it's now in the 320's, so no guarantees]).

Also, I remember from the Sophos install stating if I didn't want the enterprise features, it would only be a basic linux OS... I think a good place to start may be checking out how the openvpn script is written for a linux distro.  I may not have time to do so tonight, but will tomorrow at the latest.

I would assume if the openvpn script(s) running on the backend were edited, this would allow UTM to function as a client, right?

Here's where things get tricky from both technical and legal/contractual perspectives.

As you may have noticed JW, Sophos has made many customizations to the backend, such as with many conf files.  In a normal *nix distro, you would edit the .conf to make a change.  Well, UTM has a configuration database called confd, which stores many settings and writes then into conf files, so as changes are made to the configuration, they are written out to conf files, obliterating any custom changes you may make in the conf files directly, sometimes within seconds.  The temporary way around this is to make changes into the relevant conf-default files instead.  I say temporary because when u2d patches are installed, for a given portion of the UTM, all files for that section will be overwritten.  So, if you want to stay current with patches/updates, potentially once a month you'll be resetting those custom changes and needing to diff the backup conf-default with the new patched one in case something has been altered to fix an issue.

On the legal/contractual side, the above only applies to home users.  For the paid business users, manual changes done to the backend by users without the express permission of support (this is given rarely, except to fix known issues there is not currently a patch for, and never to add or change functionality) voids support and warranty until reverted with a fresh install.

...Sophos has made many customizations to the backend, such as with many conf files.  In a normal *nix distro, you would edit the .conf to make a change.  Well, UTM has a configuration database called confd, which stores many settings and writes then into conf files, so as changes are made to the configuration, they are written out to conf files, obliterating any custom changes you may make in the conf files directly, sometimes within seconds.  The temporary way around this is to make changes into the relevant conf-default files instead.  I say temporary because when u2d patches are installed, for a given portion of the UTM, all files for that section will be overwritten.  So, if you want to stay current with patches/updates, potentially once a month you'll be resetting those custom changes and needing to diff the backup conf-default with the new patched one in case something has been altered to fix an issue.

Thanks! =]  That explains a lot, especially why openvpn confs are created dynamically and subsequently deleted when the vpn profile is disabled.

Would I be correct in assuming then since Sophos doesn't want OS files modified via the cli (completely understandable why they don't, for a myriad of reasons), there's no literature or write ups on how one would go about modifying specific database files run by confd?  My thought process is if circumventing certain lines of code isn't practical due to confd, could one simply circumvent entire files by running openvpn from static files?  Instead of utilizing the /var/mdw/scripts/openvpn script, could a custom script be utilized to call and run openvpn (for example, customizing one from a linux distro, or the distro UTM is based on if confd isn't utilized on it [I'm referring to the option during installation where it asks if you want to install enterprise features or refuse and get a basic Linux distro]) 

[SIZE="1"]**DISCLAIMER: Making any changes via the command line interface [cli] results in the loss of support and warranty for paid licensees**[/SIZE]

So... I DID manage to email Sophos and ask them about this.

In the end, Sophos does NOT support setting up the Gateway as an OpenVPN Client, at all (regardless of support level); such functionality does not exist. Sophos support suggested that create a feature request for such a...feature.

Comically enough, one such featuyre request does indeed already exist. In fasct, it is THE #1 requested feature (by a VERY wide margin):
UTM (Formerly ASG) Feature Requests: VPN (173 ideas)

Given that the request was first created over 5 YEARS ago and does not appear to have had any response or comment from Sophos, I would not (and do not) expect anything from them anytime at all.

So, that means it's up to us to break the (non-existant) warrantee and hack that functionality.

From my knowledge of OpenVPN, assuming Sophos is using a fairly generic implementation of the OpenVPN binaries (it would theoretically be possible that they have removed the code for client functionality entirely), all we would need to do is just use a proper config file, point to the proper certs, and away you go.

And even if they DID remove the client functionality, since the base OS is Linux based, all we would need to do is find the right kind of binaries (and possible prerequisites) and use that, along with configs and certs, and set up a script to do the connecting and monitoring... This couldn't be monitored through the WebUI, but SHOULD be do-able...

So... I DID manage to email Sophos and ask them about this.

In the end, Sophos does NOT support setting up the Gateway as an OpenVPN Client, at all (regardless of support level); such functionality does not exist. Sophos support suggested that create a feature request for such a...feature.

Comically enough, one such featuyre request does indeed already exist. In fasct, it is THE #1 requested feature (by a VERY wide margin):
UTM (Formerly ASG) Feature Requests: VPN (173 ideas)

Given that the request was first created over 5 YEARS ago and does not appear to have had any response or comment from Sophos, I would not (and do not) expect anything from them anytime at all.

So, that means it's up to us to break the (non-existant) warrantee and hack that functionality.

From my knowledge of OpenVPN, assuming Sophos is using a fairly generic implementation of the OpenVPN binaries (it would theoretically be possible that they have removed the code for client functionality entirely), all we would need to do is just use a proper config file, point to the proper certs, and away you go.

And even if they DID remove the client functionality, since the base OS is Linux based, all we would need to do is find the right kind of binaries (and possible prerequisites) and use that, along with configs and certs, and set up a script to do the connecting and monitoring... This couldn't be monitored through the WebUI, but SHOULD be do-able...

I haven't had the time yet to thoroughly look at the Sophos config files, however if you haven't yet, read Scott's last reply.  Sophos uses confd to create and adjust conf files on the fly, which is why the openvpn config files are created dynamically and subsequently deleted.

In theory, your thought process should work, however I'm wondering if simply compiling a second openvpn installation onto Sophos would be simpler, otherwise we have to work with confd, something I have no experience with.  When I have time, I'm going to install UTM in a virtual machine and decline the option to enable enterprise features thereby leaving just the linux base OS that Sophos is built upon to see if I can get a better idea of what may work