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

Forum for HA and Autoscaling UTM deployments @ AWS?

I feel like it would be beneficial to have a separate sub-forum specifically for discussing UTM deployments in the AWS environment.  Particularly for those of us working on getting the HA and/or Autoscaling implementations to work properly.  While the webpage here: www.sophos.com/aws seems to suggest that AWS integration is a widely used and perfectly tuned feature of the UTM, those of us who have been tinkering around with it know that Sophos still has a ways to go in ramping up their own internal expertise and supporting documentation for this use-case.    All the more reason for easy channels for collaboration among the community.

At the very least, I'd love to hear from anyone else out there who's currently working with the HA implementation.  I'm alternately impressed and frustrated with it thus far :)  but I think it could be a truly amazing product with a bit more fine tuning-- and I think strong community involvement is going to be the driving force to make that happen.  



This thread was automatically locked due to age.
Parents
  • I for one just signed up and joined the Sophos Community for this exact topic reason.  So far I've had good success with deploying Sophos UTM 9's in our AWS VPCs to meet specific needs but now I am going down the HA path as well.  I just spun up a brand new Sophos UTM using a Market Place subscription in order to model a HA configuration using the "Convert to HA/Autoscaling Setup" feature vs deploying the available CloudFormation templates available via Knowledge Article ID: 122202.

    First step was reading the HA/Autoscaling section of the UTM 9.4 Administration guide.  Everything seemed straight forward so I did the following:

    1. created the necessary IAM Policy for the conversion process and end result CloudFormation template and auto scaling group to do their thing
    2. created a dedicated IAM user for the Sophos HA function and assigned the policy from step #1
    3. generated AWS access keys for the new user
    4. filled in the access key and secret access key in the Conversion tab under Management->HA/Autoscaling
    5. Selected the HA (Warm Standby) configuration type
    6. Clicked the "Conversion Pre-Check" button to watch the magic unfold

    As per lprikockis post that started this forum, I'm unfortunately purely in the "frustrated" category at this point. [H]  This is due to the "magic" that unfolded from step #6 in the process was the following:

     There is currently no migration path available for your version. A migration path will likely be made available soon. Try again in a few days

    Seriously?  Why have the option enabled in the Webadmin console if it is unavailable?  Given, I had immediately upgraded the newly minted UTM to the latest and greatest firmware (9.403-4) figuring it would have the most stable HA support am I now going to go back to square 1 and deploy another new instance and upgrade one firmware release at a time to discover which one is the "magic" version?  Certainly not a good use of my valuable time. [:O]

  • ugh... I had tried that upgrade functionality a month or so ago when it first appeared and had the same result.  So much for "try again in a few days" :(

    I am not currently aware of ANY version that can successfully use that "conversion" functionality.    I'd be happy to be proven wrong by someone from Sophos, but I don't think that feature works yet.

    My only success with either the HA or autoscaling UTM (they are, by the way, two distinct branches of the UTM 9 family at the moment) has been to spin up a brand new instance using the CloudFormation templates as described here https://www.sophos.com/en-us/support/knowledgebase/122202.aspx (HA) or here https://community.sophos.com/kb/en-US/122742 (autoscaling)

    I'm still waiting on a viable path for directly converting a "standalone" UTM to one of the newer versions.

  • Thanks for the update on your end.  For the record I did completely roll-back to a new instance, applied the firmware updates one at a time to discover that 9.401-11 enables the HA/Autoscaling option under the management section.  Of course to no surprise I received the same "try again in a few days".  I then updated to 9.402-7 and tried again (Einstein would be proud of me for proving fulfililng his quote on insanity [:O]) but to no avail.

    Thus, I've moved on toe using the same templates available in the Knowledge article.  Frankly I was just hoping to generate a fresh template from the conversation to be retrieved from the CloudFormation UI as I'm going to need to hack the heck out of it anyway to meet our needs (multiple interfaces, the HA cluster within one AZ, etc.) so now I'm just doing that to the downloaded template.  The reason for trying the conversion was just to have the template generated using the existing VPC.  So now I"m hacking the stock one to do so as well.  Yes, it might sound weird to run the auto scaling group within a single AZ but that is by design given I'll be running two clusters one in each AZ that will operate independently but provide HA within the AZ as two subnets behind the UTM are set to default route to the UTM interfaces for them.  The UTMs are in a dedicated DMZ VPC so I need all traffic to go through the UTM's IDS/IPS prior to heading either to another set of VPC via a peering connection (there is an interface for that) or to a VPG into our MPLS mesh (dedicated interface for this too).  

    The worse case scenario is I just run an autoscaling configuration (have fully tested that) with its single interfaces and then deploy "stock" (still hacked for one AZ and existing VPC) HA warm standby clusters to protect the peering and VPG routes.  Just ends up being 3 times the amount of instances and Sophos licensing for each AZ.  Plus, the Ingress traffic does not really warrant the need for autoscaling.

  • UPDATE: apparently I did not wait long enough in the 2nd launch for the EIP to be attached and take over (removing the public address initially assigned) so designating an existing EIP in the stock template does work.

    Just an update along with a plea for help from anyone knowledgeable.  I have successfully "upgraded" the stock warm standby template to incorporate the needed changes: use existing VPC, multiple NICs (handled via user data in the launch config), etc.  However, I am stuck on one thing that I have not touched whatsoever in the original code as for the most part I'm leaving it as-is with the enhancements.  If I supply an existing EIP it is not used and both nodes just end up with a public IP as per the launch configuration.  For a sanity check I just did the following:

    1) Performed a clean launch of a warm standby cluster using the template from the S3 bucket maintained by Sophos into a new new VPC defined as "10.90" and did not supply a EIP in the parameter list.  Everything came up as expected with one node owning an EIP and the other just a public address.

    2) Performed a 2nd clean launch utilizing "10.150" as the VPC CIDR and provided an existing EIP.  End result is what I expected, i.e., 2 nodes both with public IPs and no EIP.  So it definitely appears there is a bug in their code somewhere.

    Has anybody successfully launched a warm standby cluster using an existing EIP?

  • Hi Ray,

    I have raised this internally, and will update you when I have a response.

    Thanks.

    Peter

Reply Children
No Data