UTM as VPN "Client"

I'm curious, JD.  What is the reason for needing the UTM to act as a client?

Cheers - Bob

My customer wishes to pseudo-anonymize their traffic going through this gateway. They have settled upon using a VPN Service (just about any, really) that is OpenVPN compatible. In the end, this is my task, to find a UTM (single device/gateway) capapble of this, as well as expected UTM features. The OpenVPN Client criteria is killing me...lol...

Fastest way, get another router, james already has all the steps written down.
Not so fast but doable, Use a VM, RUN UTM as your gateway and run ubuntu/debian depending on your linux skills as your VPN gateway behind the UTM. You can still use the UTM for all its functions and the tunnel will still work.
Hardest way, work around confd.

This is almost like the movie matrix.
JW0914= Neo (He is the one[[:D]])
JDMoore= Morpheus (Believes He is the one)
Confd=Agent
Scott=Architect (Knows all about it)
Billybob=Oracle (Don't have a clue but the answer can be applied any which way[;)])
BAlfson= The machine lol[:O][[:D]]

Fastest way, get another router, james already has all the steps written down.
Not so fast but doable, Use a VM, RUN UTM as your gateway and run ubuntu/debian depending on your linux skills as your VPN gateway behind the UTM. You can still use the UTM for all its functions and the tunnel will still work.
Hardest way, work around confd.

If it comes down to it, this IS what we'll have to do. But THE reason I have been looking into UTMs is prevent the need for any additional hardware... 1 appliance to do it all.

This is almost like the movie matrix.
JW0914= Neo (He is the one[[:D]])
JDMoore= Morpheus (Believes He is the one)
Confd=Agent
Scott=Architect (Knows all about it)
Billybob=Oracle (Don't have a clue but the answer can be applied any which way[;)])
BAlfson= The machine lol[:O][[:D]]

I hadn't laughed this hard in a while...lol...

Bill, you are crazy funny!  My son is creative like that.  He does improv in NYC ("North Coast NYC").  They have a weekly show Saturday nights at 8PM at the People's Improv Theatre (The PIT).  The next time you're in NYC, it will be the most fun you can have for ten bucks!

Uh, JD, if I were you, I'd be careful not to learn too much about this guy's business. [:O]

Cheers - Bob

Care to share said manuals?

I know I downloaded a few, and I'll find the rest at some point, but here is the one I saved because it was the most in depth:

ConfD Kick Start Guide.zip

If you were looking at https://github.com/kelseyhightower/confd, the UTM one is completely different, homegrown.  There is no manual, because Sophos doesn't want users messing around with it.  There's a handful of kb articles with a few commands here and there in the public knowledgebase, like https://www.sophos.com/en-us/support/knowledgebase/116041.aspx.  Confd does have a little built-in help, once you enter cc.

I hadn't looked at those, but will now =]

This part is going to get difficult since this is what is considered part of the enterprise tool kit. Confd works in conjuction with middleware. Hence the reason for the init scripts in 
I haven't tested how long manually created additional interfaces / routes stay alive with last few releases since v9.1. Scott has more experience with that. 

Here is the list of problems I foresee:

1. If you don't make confd/mdw aware of your interfaces, they will get removed. What will trigger that and how often will need to be investigated.

2. If you ignore confd and add additional interfaces anyway, confd will still wipe off your iptable rules and any additional routes wiping any progress.

3. If you install a binary, any update can wipe your dependencies. If you can find an rpm that works, it may make the sophos system updates fail but I think they force the rpm updates which may leave your whole system unstable after an update.

4. Chrooting won't help since confd can change your base network anytime.

5. If confd is not aware of your manually added network/routes. Even if they survive for a period of time, all the other daemons such as snort (IPS) won't know about your local and remote network and block such traffic actively. So you will either have to disable IPS completely or will have to modify snort conf files which will again get overwritten by confd =]

6. Installing without enterprise root kit throws you at grub> prompt when I tried it a few years ago. I am not even sure if they include a compiled kernel without enterprise root kit. Besides, what would be the point? We know openvpn works on linux[[;)]]

This is all I can think of at the moment. Thats why some people suggest workarounds by using additional hardware vpn routers or site to site with another distro that can do open vpn correctly.

 If I was going to do it with software on the UTM, I would first find a binary that would work on the UTM. Then I would start working on finding workarounds one obstacle at a time.

It would be interesting what you find out reading the confd. literature. I am sure that is some dry reading =]

Thanks, I wasn't aware of most of that.  I know a few had been stated previously by Scott or Bob (I think), but that's definitely an indepth explanation as to why getting the UTM to act as an OpenVPN client is even less likely.  Even if it's not possible to work around/with confd, I'll still read the literature since I've never heard of ConfD prior to this thread and it sounds like a fairly useful tool to know the basics of.

Fastest way, get another router, james already has all the steps written down.
Not so fast but doable, Use a VM, RUN UTM as your gateway and run ubuntu/debian depending on your linux skills as your VPN gateway behind the UTM. You can still use the UTM for all its functions and the tunnel will still work.
Hardest way, work around confd.

My customer wishes to pseudo-anonymize their traffic going through this gateway. They have settled upon using a VPN Service (just about any, really) that is OpenVPN compatible. In the end, this is my task, to find a UTM (single device/gateway) capapble of this, as well as expected UTM features. The OpenVPN Client criteria is killing me...lol...

If your customer hasn't already bought hardware, I echo Billybob, as that's my eventual plan.  I plan on running Sophos within a VM with a linux distro in a separate VM (ESXi as the base OS).  It's why I bought the SuperMicro A1SRi-2758F motherboard (2.4gHz octa-core, 20w TDP, 7 year product life), as I'll be dedicating 5 or 6 cores and 16GB of RAM to Sophos, with the remainder cores and RAM dedicated to a linux distro.  It's a fairly expensive server board for a router, but I bought it because it was only $100 more than the quad core 2558.  If your customer decides to go with Intel's SoC 255x or 275x, ensure they choose the SoC's ending in 8, not 0 (i.e. 2558/2758, not 2550/2750); as the SoC's ending in 8 were designed with networking in mind and have a specific networking feature built into the processor (however I believe the feature isn't currently supported in UTM, but I saw it as a long term investment).  They, or you, may want to compare the 4 using Intel's comparison tool on their site if they decide to go that route.

Sophos UTM runs the same if it's in a VM or as the singular OS.  I was introduced to Sophos by a dev on the FreeNAS forums, and he's run his UTM implementation out of a VM for years.

I'm not sure how tech savy your customer is, however they wouldn't even need to run a VM of a full Linux distro if all they were going to use it for was OpenVPN.  They could install FreeBSD and simply configure it to only run OpenVPN and not bother installing GUI functionality.  

• I'd assume status could be obtained via SNMP or by simply viewing the two log files (main and status logs). 
  
• I've never been a fan of OpenVPN GUI integration, as I've yet to come across a single instance where it's a fluid integration without discombobulation, while still offering full functionality.  
  
• OpenVPN is extremely simplistic by design and issues are almost always fairly easy to troubleshoot in a matter of minutes.

I'm not sure if your customer cares about the aesthetics of the housing, but the In Win Chopin mini-itx case is what I'll be purchasing when it's released later this month or next month.  Currently I'm using a Habey EMC-800BL case with the white insert removed (it has a nice black, brushed satin finish to all sides)

This is almost like the movie matrix.
JW0914= Neo (He is the one[:D])
JDMoore= Morpheus (Believes He is the one)
Confd=Agent
Scott=Architect (Knows all about it)
Billybob=Oracle (Don't have a clue but the answer can be applied any which way[[;)]])
BAlfson= The machine lol[:O] =]

LOL =]

I know I downloaded a few, and I'll find the rest at some point, but here is the one I saved because it was the most in depth:

[ATTACH]14918[/ATTACH]

That ConfD attachment is unrelated to the Sophos, formerly Astaro, confd found on the UTM, SUM and iView v1.  Don't overlook Scott_Klassen's post at https://www.astaro.org/gateway-products/vpn-site-site-remote-access/59751-utm-vpn-client-4.html#post310010

The origin the attached ConfD PDF appears to be ConfD Evaluation Kick Start Guide

Also, the cc that is discussed on this forum is not a C Compiler but an alias for confd-client.plx.

That ConfD attachment is unrelated to the Sophos, formerly Astaro, confd found on the UTM, SUM and iView v1.  Don't overlook Scott_Klassen's post at https://www.astaro.org/gateway-products/vpn-site-site-remote-access/59751-utm-vpn-client-4.html#post310010

The origin the attached ConfD PDF appears to be ConfD Evaluation Kick Start Guide

Also, the cc that is discussed on this forum is not a C Compiler but an alias for confd-client.plx.

So is ConfD unique to each OS it's implemented on?  I had never heard of ConfD prior to this thread and I'd like to learn more about it (mainly the basics), so is it not a daemon that's roughly the same across implementations?  (I know the manner in which ConfD is implemented within an OS would be different from OS to OS, however I assumed the basics would be the same... is this assumption wrong?)

So is ConfD unique to each OS it's implemented on

The one you found on the web and the component of UTM are two completely different products, by different people, that happen to use the same name.  As I mentioned earlier, confd (confd-client) on the UTM is completely home grown, coded at Astaro and never released externally.

so is it not a daemon that's roughly the same across implementations?

See the above.  [:)]