Guest User!

You are not Sophos Staff.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

When will the the UTM update to current StrongSWAN build?

Upgrade to modern version of StrongSWAN which uses charon instead of pluto

The ipsec binary in use today is from 2010 still. Wouldn't it be a good idea to be on top of the versions? Particularly since Sohpos is one of the big guys listed as sponsoring the StrongSWAN project, which is what gives IPSec VPN capabilities to the Astaro?


This thread was automatically locked due to age.
  • Good job!  I've voted and commented.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I don't get updates on feature comments.. so just duplicating my response to yours here:

    Exactly, Bob.. in "Advanced" section it should allow setting LEFTID or any other ipsec setting that exists. To be least amount of effort on Sophos part, with the most amount of features and flexibility, I envision this:

    Advanced section would display a table-like list of all the ipsec.conf settings for a selected VPN Connection that the GUI already puts in there. 
    Then allowing you to add and edit others.

    Very simple design, not worrying about having to add bunch of UI logic or whatever to handle things that ipsec can already do.

    LEFTID is not the only one. There are several other options that are simply not possible due to the lag of the UI. The only real super benefit to the UI is how it forces you to create a Named Network definition for everything. But with just a little bit of work, that can be done for this Advanced thing also by just maintaining a list of ipsec.conf settings whos input is some IP address or whatever. When those values are added/changed the UI could restrict to first creating a Network Definition
  • Bob.. you're in Oklahoma?  Did you get by without harm from tornadoes?
  • Yes, we did, thanks.  The tornado passed through Moore, 14 miles south of our home, and the office is northwest of my home.  Although the tornado sirens kept sounding occasionally all afternoon, we had only heavy thunderstorms and very little hail.

    Of friends and colleagues, only one (so far) is known to have damage - a large shard of debris fell from above and is sticking out of the roof, piercing down through ceiling and walls into the floor.  Luckily, both of them were still at work and their children's homes weren't in the path of the twister.

    There's a positive energy here - not much hopelessness.  The only pervasive sadness is for the elementary school kids that suffocated beneath the rubble of their school.

    Two years before the 1995 bombing, Oklahoma City had passed a special "MAPS" tax to do things like build a new ballpark (looks like Boston from the outside, and feels like Texas on the inside) and the arena that eventually became the home for Thunder Basketball.  Just as the bombing in 1995 did for OKC, the 1999 tornado that hit Moore increased people's desire to make the community better and to help others build and rebuild.  In the wake of the tornado, there's a lot of positive energy amongst those that lost their homes, posessions and cars.  And the level of personal kindnesses and charity from here and others near and far is awe inspiring.  Two of the primary charities have been American Red Cross Central and Western Oklahoma Region and United Way of Central Oklahoma - if anyone wants to give to them, note your donation with "May 20, 2013 Moore, OK tornado" - thanks.

    Again, thanks for asking.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • An interesting observation. First of all, ipsec VPN's in Astaro somehow do not reset themselves when they should. We have about 50 of them running on our instances and every week there are a several instances where we have to reset it and it just works. Sometimes the VPN connection is detected as down and the DPD is not helping. Sometimes the VPN connection is detected as up, but traffic is not routing. In both cases, when we disable and re-enable the connection, it's good.

    That's of course why I had to write scripts to try to automatically manage this (in another post).

    Anyway, I tried using ipsec reload to reset that way, as that's what Astaro calls when you change the settings of a VPN connection. I scheduled this to happen periodically. This seemed to work great, however apparently some of the good VPN connections were getting reset also. That caused for traffic to timeout whenever that happened, so we had to stop that.

    The interesting part is that ipsec reload is not supposed to affect VPN connections that are already up. So I wonder if because Astaro is using such an old version of StrongSWAN, that it's a bug they have fixed within the past 3 years.

    Side question though, is Astaro UI just calling ipsec reload? Or are there other parameters it sends that make it more friendly? This is important because it happens any time you change ANY VPN connection. If it does just ipsec reload, then it means that any time you change ANY VPN connection, all open VPN connections are subject to getting some disruption. And maybe the it's limited to VPN's where they have multiple IP's in the tunnel, and some of those IP's are reported as DOWN. So at that time, ipsec reload might be trying to reset them, taking out the IP's that are reported UP since they are part of the same tunnel.

    And the Astaro version does not seem to matter; I see the same behavior with a v8 we're using and a v9. Plus I know the StrongSWAN ipsec version between them is the same anyway, just a slightly different build but both versions 4.4.1.
  • Well it seems I've come across enough web articles that simply point out that the old pluto implementation of ipsec VPN is just not good enough these days to be used by a router like Astaro/Sophos UTM and likely is the reason the VPN tunnels are less stable than present day hardware routers. Our challenge is that we have to set up many ipsec VPN's with third parties who could be using all different kinds of routers. Hardware routers for whatever reason don't play nice with that situation. But pluto sadly also does not, which is silly because it's supposed to be a standard defined protocol. I'm actually making plans to build my own router now so I can have current ipsec software that's not so ridiculously outdated so I am not locked into waiting and hoping Sophos upgrades it.

    Here are some references of people's experience in moving to the current StrongSWAN charon ipsec software.
    [Development] Strongswan 5.0.0
    planet.ipfire.org - IPFire Planet
    Known Problems on site to site vpn between Sophos (Astaro) UTM and Sonicwall - Spiceworks

    Some note worthy quotes from the references:
    "...it is not necessary to restart all IPsec connections any more when one connection is edited, created or removed. That leaves us with much more stability. Changing preferences and some smaller bits are much faster and don’t require to reconnect to all the remote parties. Data transfers cannot break during this time and that is very enjoyable for every admin who cares about a couple of busy IPsec connections."

    "We are expecting (and already experiencing) a magnificent improvement of the connection stability. Especially in difficult situations, for example behind a NAT router and connections with dynamic IP addresses which change very often are getting much more fun to use."

    "Any updates on this ? Success / failure ?
    My Astaro 9.x UTM is not doing it with a Sonicwall TZ210.
    The Sonicwall initiates the connection. IKE succeeds and then The Sonicwall reports "Incompatible with older firmware" and hangs up."

    Of course here is StrongSwan's page on the pluto removal:
    CharonPlutoIKEv1 - strongSwan - strongSwan - IKEv2/IPsec VPN for Linux, Android, FreeBSD, Mac OS X
    which covers a few still missing features. Of course, those missing features can be handled by also running the old version.. or probably better spent time in just helping the StrongSWAN team complete those features.
    Or at least upgrade to the latest 4.x version of StrongSWAN from 2012 while pushing to get their latest version totally ready.
  • Sophos not making this the #1 priority of any VPN modifications (or the Astaro team from the start) to me is a conflict of interest.
    We have already moved 25% of our VPN's from Astaro to a home-built Linux instance running the latest StrongSWAN software. The result is higher stability and superb support; very technical feedback and almost instant bug fixes when problems are found. We have a plan in place to move 100% of our VPN's off Astaro within a few weeks. It's sad because the Astaro UI is really nice and everything else it does is OK, but I guess it's all meant to be like a Wal-mart: just barely good enough for the average Joe, but if you need something solid gotta shop elsewhere.

    I have a simplified version of my ipsec monitoring script that resets VPN's when they are not functioning that works fantastic with the newest StrongSWAN software. 

    From our experience we concluded that VPN's are not designed for handling lots of different types of connections, which is what we deal with. But very simply the StrongSWAN ipsec software is 100% capable of handling it if the user is allowed to control it fully, and also having the latest version of it.
    On top of that, there are definitely situations that the VPN thinks everything is fine, but traffic stops working. It may or may not be the StrongSWAN's side at fault; it could be the other side messing up. None-the-less, the only resolution at that time is to take down that connection and bring it back up.

    Also, the auto=start configuration that Astaro forces you to use is actually kind of crappy compared to the  auto=route  option. And this is because if a request comes in while the VPN connection is not up, if auto=start then the request fails. But if auto=route the ipsec software will start bringing the tunnel up, and the request is delayed until a timeout or the connection is up, resulting in a success if the VPN simply had to be brought back up.
  • Hi,

    Thanks for posting this; please also mention to your reseller if you haven't already.

    Barry
  •  
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA

  • I have a simplified version of my ipsec monitoring script that resets VPN's when they are not functioning that works fantastic with the newest StrongSWAN software. 


    I'd be interested in seeing what you're doing to check for and deal with this since I've seen this happen a few times with UTM as well.  VPN is "up" but all of a sudden no traffic is going across the tunnel until I "reboot" it (the ipsec tunnel that is).

    Along the same lines, is there anything exposed via snmp that would allow me to monitor the status of s2s vpn tunnels on the Sophos UTM?

    Of course, I'm hoping that sometime in my lifetime Sophos updates the Strongswan version they're using.  I've been adding votes to your feature suggestions at every opportunity.  maybe they'll eventually listen.