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

High Availability in AWS?

Hello,

We recently moved to UTM virtual appliances from Cisco ASA's, and overall we couldn't be happier. However, we are running into a pretty nasty situation trying to make sure our UTM isn't a single point of failure in AWS. Unfortunately, during the sales process we were pointed to the AWS HA support article and there's nothing on the page to indicate that it's a beta that isn't currently working.

So, we're in a position of trying to figure out how become fault tolerant with our UTM. Assuming (and hoping) we're not the first people to try to do this, how have other's achieved the same goal?

The only options I see now are:

(1) Setup a second UTM, in a different availability zone and use an Amazon ELB to split traffic between them. The UTM in each AZ would route traffic the subnets in their respective AZ. 

This solution works without AWS-specific script writing, but I'm not sure how (or if) we can sync the common configuration (everything but the interfaces). Also, it comes with a lot of badness:
 - The loss of one UTM would effectively close out an entire AZ until it was resolved or was traffic re-routed. 
 - Using an ELB means all traffic has a source address of the ELB, so lots of UTM features become unusable (unless the UTM supports the Proxy Protocol, which I can't find any docs about).
 - If you want to do anything at all with the client ip's in an HTTPS application (restrict, log, etc), now the ELB has to perform ssl termination for you so it can add the X-Forwarded-For header.
 - It costs more.

(2) Roll our own cloudstack solution to spin up a snapshot of the UTM in case of a failure.

This would have us modeling the currently-not-working HA solution brought in by sophos. This is both pretty challenging from a testing standpoint, and pretty frustrating from a development standpoint, because we would have to learn the sophos provisioning software (without even direct access to source). 


Sooo… how has this been achieved? What are others doing?


This thread was automatically locked due to age.
  • I believe it might now be available in version > 9.310 as per below?
    https://www.sophos.com/en-us/support/knowledgebase/122202.aspx
  • David,

    Unfortunately that's not the case. I've had to go back and forth with Sophos on this for a few weeks now. The HA solution provided in the KB article won't work for pretty much anybody anywhere because:

    • It is hard coded to the "US East (N. Virginia)" region. That’s one of the 8+ AWS regions. So, if you had an AWS VPC in, say Asia or the US west coast, you can’t use the solution.
    •  Even you happened to be in "US East (N. Virginia)", it also hard-codes 3 availability zones (out of 5+) in that region - "us-east-1c, us-east-1d, us-east-1e”. If you just happened to be in "US East (N. Virginia)", but were not using exactly  the availability zones described, again, it wouldn’t work. You would end up with a UTM in an AZ that you can’t contact.
    •  It hard codes 3 subnets named "Subnet1-3", with the networks of  {{VPC_PREFIX}}.1.0/24,  {{VPC_PREFIX}}.2.0/24, and  {{VPC_PREFIX}}.3.0/24 to place the UTM into. There is no way for somebody to know that their VPC MUST contain exactly these specific network prefixes, and that’s not going to work for places that didn’t defined (or can't define) /24 subnets in their VPC.
    •  There are other hard-codings, like having the UTM take over the entire VPC gateway… If you had gateways in an active/active setup, well, that’s toast.
    •  It hard codes a single interface/ip resource to the UTM. If the UTM uses more than 1 IP, it can’t be used. 


    So, basically, the Sophos solution won't work for anybody that:

    [LIST=1]
    • Has an existing VPC and is not creating a brand new one
    • Does not define exactly the 3 subnets as Sophos defined them
    • Uses more than 1 IP
    • Is not in the specific hard-coded regions and Availability Zones
    • Has more than 1 route
    [/LIST]

    Which is pretty much everybody.
  • Hi tkent,

    Just wondering how you've progressed with this?

    Originally we had proposed using the original suggestions from Sophos for HA within AWS where by it used ELB's in the front & rear of the two UTM's.

    However then we were converted to the idea that this solution to auto-scale, and use the warm-standby, however reading your posts, it seems you've run into quiet a few issues here, rather than re-invent the wheel i was hoping to see / hear how you went after all this, as we need HA, but we don't necessarily need the Auto-Scale side of things (as the environment / expected usage is quiet small)

    Love to hear your thoughts.

    Cheers!
  • I did manage to create an HA with my Sophos UTM deployment on AWS. However, my UTM deployments always involved creating two ethernet interfaces for the setup. 

    Outside or Public: Gets created with Elastic IP allocated to it.
    Inside: Need to create this interface using User data in auto scale. 

    Any tips on how to create the secondary interface each time the Sophos UTM box migrates to a new AZ when it notices a failure on the box? 

    I followed this very useful thread and posts by AlanT to get the HA solution working: https://community.sophos.com/products/unified-threat-management/astaroorg/f/115/t/73188