Results 1 to 9 of 9
  1. #1
    Master Untangler dmor's Avatar
    Join Date
    Jun 2009
    Posts
    686

    Default Controlling IPsec from the CLI

    Is there a way to activate/deactivate individual tunnels from CLI? What about turn IPSec completely on/off from the CLI?

  2. #2
    Master Untangler dmor's Avatar
    Join Date
    Jun 2009
    Posts
    686

    Default

    Bump

  3. #3
    Untangle Junkie dmorris's Avatar
    Join Date
    Nov 2006
    Location
    San Carlos, CA
    Posts
    17,486

    Default

    No.
    Attention: Support and help on the Untangle Forums is provided by volunteers and community members like yourself.
    If you need Untangle support please call or email support@untangle.com

  4. #4
    Untangle Ninja
    WebFooL's Avatar
    Join Date
    Jan 2009
    Location
    Sweden (Eskilstuna)
    Posts
    5,049

    Default

    Hmm..
    You should be able to use ucli to turn the service on and off again using the cli but that will turn off all the tunnels.


    Just run "ucli" and you will get what syntaxes are allowed.

  5. #5
    Master Untangler dmor's Avatar
    Join Date
    Jun 2009
    Posts
    686

    Default

    We ended up having to use a SonicWall for this one scenario.

  6. #6
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,510

    Default

    That's funny, because there's no command line AT ALL with SonicWall.

    So why did you need this? And how are you automagically setting up and tearing down tunnels with Sonicwall?
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  7. #7
    Master Untangler dmor's Avatar
    Join Date
    Jun 2009
    Posts
    686

    Default

    Quote Originally Posted by sky-knight View Post
    That's funny, because there's no command line AT ALL with SonicWall.

    So why did you need this? And how are you automagically setting up and tearing down tunnels with Sonicwall?
    We weren't necessarily after a CLI. We needed to interface to a SonicWall that our client had at their H.Q 3 hrs away. H.Q. I.T. is managed by a different company. Between them and our clients' upper-level management, they were absolutely unwilling to let us install an UT NG at H.Q. even just for the purpose of serving the outlying branches (i.e. not to affect their H.Q. internet at all).

    Anyway, their SonicWall is setup to provide an IPsec tunnel that we've been connecting to via the UT at the branch office here where we manage the I.T.

    Problem becomes the multi-ISP situation. Seems like nearly every week one of the internet connections go down (H.Q. has 2 for redundancy and here at the branch, we also have 2). When this happens, branch employee productivity is severely impacted.

    They have the SonicWall at H.Q. configured to allow us to connect to the IPsec tunnel via either of their public IPs. And I'll say that it works quite well. If one of their connections goes down, all we have to do is change the IP of the endpoint in the tunnel config on the UT, and we're back up & running. Pretty cool.

    However, this manual intervention on our part is still not acceptable, as there are sometimes delays, and these guys work outside of our business hours (we keep someone on call, but the execution isn't always as quick as business hours).

    So our hope was that UT would modify the IPsec service to allow for an alternate IPsec peer IP to be defined for any given tunnel. That's how SonicWall does it and they fail-over automatically and quickly. UT hasn't done this yet. So I was hoping that we could automate this ourselves by writing a bash script in a cron job that pings the inside interface of H.Q. firewall every minute, and if no packets are received, then change the IPsec config to tear down the tunnel we're using and bring up the alternate tunnel (i.e. pointing to H.Q.'s other IP). Not a perfect solution, but would be much better.

    Without the ability to do this from the CLI, seems we are currently out of luck on the UT side.

    Additionally, I got a call from H.Q.'s I.T. last week saying that upper-management just told them to get a SonicWall installed at the branch we support ASAP. I had also come to terms with this same solution just a couple days earlier, so I didn't resist at all.

    There will probably be a SonicWall installed in the coming 2 weeks. Would be nice to see UT provide this entire solution. Maybe they will in the future. For now, we'll continue to use the UT as the primary firewall for protecting/controlling the internet edge traffic, then just have a static route to send the H.Q. traffic over to the SonicWall.

    Do you think there was still some other way we could have achieved this with UT whilst not being allowed to install an UT down at H.Q. (which would have been an OpenVPN site-to-site solution for multi-ISP redundancy)?

  8. #8
    Untangle Ninja sky-knight's Avatar
    Join Date
    Apr 2008
    Location
    Phoenix, AZ
    Posts
    26,510

    Default

    Ahh IPSec failover! That makes sense!

    Sadly no I'm aware of no way to do that with IPSec within Untangle.

    You know the goofy part is, an alternate IPSec host for a given tunnel is a security risk, and a perversion of the IPSec protocol. The real answer to this problem is to have two tunnels up, all the time, and use dynamic routing over both to maintain connectivity. That way you maintain the integrity of the tunnels themselves, and you get your resilience. Untangle can't do dynamic routing, so this is not possible either.

    Given your situation, I would have gone with the Sonicwall up front. As much as I love Untangle, in this case it's not really the IPSec situation that will kick you, it's the support gap. When working in a multi-IT environment, it's best to settle on a solution both sides of IT can support. Otherwise you waste precious time teaching, training, or explaining a "strange configuration".

    That's why Sonicwall is so ubiquitous, that's also why Cisco is so ubiquitous. They've gotten to the point where most things run on them. Features are important, but familiarity is what sells.

    OpenVPN might have worked, because you can use DNS to manage the connections. However you'd need an OpenVPN service to terminate on. That doesn't have to be another Untangle, but getting an OpenVPN server to play predictably would have been considerably more work on your part.

    If it were me? I'd have shoved out the Sonicwall too, even while trying not to puke while doing it.

    What you might have been able to do is write a script to rebuild the IPSec configuration and restart the IPSec module. But you're straying off the support path and into hackery here, sure it's likely possible. But again why?
    Last edited by sky-knight; 10-08-2014 at 08:01 AM.
    Rob Sandling, BS:SWE, MCP
    NexgenAppliances.com
    Phone: 866-794-8879 x201
    Email: support@nexgenappliances.com

  9. #9
    Master Untangler dmor's Avatar
    Join Date
    Jun 2009
    Posts
    686

    Default

    Quote Originally Posted by sky-knight View Post
    The real answer to this problem is to have two tunnels up, all the time, and use dynamic routing over both to maintain connectivity. That way you maintain the integrity of the tunnels themselves, and you get your resilience. Untangle can't do dynamic routing, so this is not possible either.
    Yep. This is a feature one of my support engineers keeps asking me to request from UT. He has spent much time supporting medium to larger enterprises & has supported a lot of different firewalls in the process. UT has grown on him a lot, but this is the one feature he strongly feels it lacks. Actually he wants Dynamic Routing and Policy-Based Routing.

    Quote Originally Posted by sky-knight View Post
    When working in a multi-IT environment, it's best to settle on a solution both sides of IT can support. Otherwise you waste precious time teaching, training, or explaining a "strange configuration".
    Agreed

    Quote Originally Posted by sky-knight View Post
    What you might have been able to do is write a script to rebuild the IPSec configuration and restart the IPSec module. But you're straying off the support path and into hackery here, sure it's likely possible. But again why?
    I felt the same way. Implementing a hack like that, although it may work also feels like asking for trouble.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

SEO by vBSEO 3.6.0 PL2