Forum for HA and Autoscaling UTM deployments @ AWS?

The auto scaling is not working I'm stuck at this point

Issue was caused by not having an AWS market place license for the secondary HA unit, went to the market place and added a secondary subscription.

After deploying in HA what is the default user name and password because the conversion dosnt carry over the username and password I cant log into the Firewall after the conversion.

Hi Vitale,

Thanks for the feedback and update. Someone from our Solutions Architect team will reach out to touch base with you. Ping us at aws.marketplace@sophos.com if you need anything else.

Guys @ Sophos I dont mind being the beta tester But I have a live AWS production environment and need stable HA firewall implementation ASAP I have benn patient

1) Waited for multiple sophos  releases

2)Deployed and talked to product engineering about set backs of HA deployment

3) Got on a phone call with video recording to Show current Sophos UTM 9 HA pair cloudformation issues and adjustments that Sophos needs to take,

4) Unable to pick my own production DMZ or Public subnets when running a HA conversion ? This needs to be fixed asap Sophos by default takes existing Subnet and as an example changes the Third octet for a New public subnet  in my case sophos created 10.74.1.0 public subnet One and Public subnet two 10.74.2.0  in my prod environment My subnets are 10.74.3.0 and 10.74.4.0 Sophos needs to adjust and let the customer choose where the HA conversion AMI are deployed.

With the Above point NO one can use the HA cut over in a production environment without making live route table change or adjustments.

5) When deploying the HA conversion Unable to login to the New HA pair firewalls this is an issue No default user name or password work including the one from the Source conversion firewall where the HA conversion was started.

6) The assumption that two new HA AWS AMIs are created during the conversion is ridiculous, If I already have a single production Sophos firewall running , All I want is to Hit the HA conversion wizard and have one warm firewall spin up and attach itself to my current production firewall.  This is clearly not the behavior in the cloud formation template.

The behavior when doing a new Warm HA conversion creates two new Sophos AMI's firewalls in their own public subnet inside my VPC. This dosnt make life easier it creates more complexity with end customer having to make route table and ACL changes on their production environment.

What was expected with this release.

1) To run HA conversion wizard "Warm"

2)two have a single AMI spin up

3)That new AMI is synces with S#, SNS,

4)The current production source firewall that is working and where the conversion for HA has been initiated from stays in place and works to sync with S3, SNS, auto-scaling etc.... to create HA fail-over.

This has not been done

Instead sophos took the HA conversion utility within the production firewall AMI that a comapny might have and created a path for a brand new (Subnet, HA Firewall Pair AMI, and isolated the deployment within your production VPC) 

How is this useful at all?

The consideration is the customer and company, again I wrote above what is expected and required for this to be successful, Again I'm willing to work with Sophos engineering team to test live in my prod environment.

Byron J. Watson  you are the Security Solution Architect , I did speak with you and let you video record all the issues above.  What is the update ?

Hi Vitale,

I sent you an email asking for a time to coordinate a phone call, but let me answer your questions here for other readers.

1. Two AMIs vs. spinning up a new AMI as a cold/warm spare: there are a couple of reasons why we chose the option of spinning up two new AMIs. First, in the event that a customer may want to revert back to the original AMI for whatever reason, we wanted to provide a way to access the original image and still play with the HA scenario. Second, many of our customers are using Stand Alone UTM running on PV instead of HVM. PVs are not supported by AWS in the newer regions or on newer EC2 instance types; however, there were scenarios where customers wanted to keep using PV because of pricing, compatibility, etc. for older EC2 instances types. Third, we are not planning on releasing a conversion path for customers who want to convert from HA to Auto Scaling. As such, the preserved image provides a way to test the HA on the new AMIs but also convert to Auto Scaling from the previous image to compare the two deployment scenarios. At any rate, based on your feedback we're evaluating if we can support both methods going forward, i.e., convert by spinning up two AMIs or just add a cold/warm standby. We're hoping to have this evaluation complete here shortly and will let you know.
2. We're also looking at how we can support customers using pre-existing subnets and VPCs based on your feedback. For the Auto Scaling release this may not work as the UTM Workers and OGW instances typically require new, separate subnets, but we may be able to get this to work for the HA scenario. We'll keep you posted.
3. Unable to login to the HA spare. This is by design. The account credentials and policy settings are not transferred over to the HA spare until a failover has been initiated. The reason we chose this was to reduce locations where important information like user credentials was stored. If an attacker were to compromise user credentials on an inactive system, there were limited ways on alerting customers to the attempts. However, we're always curious to understand what customers are tying to do with UTM. Can you provide details on why you need access to the secondary system?
4. Byron did provide me with the recorded video. Thanks again for taking the time to give us your feedback.

I hope this answers your questions. If not, please reach out at aws.marketplace@sophos.com. Thanks again.

Dear lprikockis:

I totally agree with your overview of Sophos UTM HA within AWS and that it's going to take a lot of community collaboration to make this a great implementation solution for AWS. . I used the Cloud Formation stack and have deployed the Sophos UTM HA within it own new VPC with a warm standby in a second availibilty zone. I have two separate VPC's, which contain Linux EC2 Iinstance in one and Windows EC2 instances in the other. I have been able to create a Peering connection to the Linux VPC and can ping hosts in that VPC. What I am stuck on is, how to route all the traffic from the 2 other VPC's using peering through the Sophos UTM using only one EIP. I believe it involves some special routing tables and security groups within AWS, but I haven't figured it out yet. Also, i want to have two VPN tunnels defined as well. I am new to using Sophos UTM, but am eager to learn all I can.

Any assistance is highly apprecitate,

Thanks,

Scott Spangler

Hi Scott,

As you may be aware, AWS doesn't allow transitive routing across VPCs, even with a peering connection. One option you could consider to overcome this is the Outbound Gateway (OGW) component of the Auto-Scaling UTM deployment (a different deployment type than the HA deployment, but also deployed via Cloud Formation). The OGW is a Sophos developed Linux based instance, which forms a GRE tunnel with the Worker UTMs in an auto-scaling deployment - this can go across a peering connection. The OGW is then configured as the target in your peered VPC client subnet's route table, to reach the Internet. However, this does require additional instances, and UTM costs, as you would need a Controller UTM, two or more Workers (1+ per AZ), and one or more OGW instances. The Quick Start Guide for the UTM on AWS contains a description of the Auto-scaling deployment - https://www.sophos.com/en-us/medialibrary/PDFs/documentation/SophosUTMAWS.pdf?la=en. It is also possible to obtain a HA UTM Cloud Formation template that deploys into an existing VPC rather than create a new one - this may be another option, but if you have two VPCs, one for Windows and one for Linux, then you would probably need two separate HA deployments.

Regards,

Peter

Hi Peter,

Thanks for bringing the transitive peering problem to my attention. What I performed on Friday night, was to roll back and delete the HA-UTM Cloud Formation Stack. Then I performed a standalone UTM install within my Linux VPC, which allowed me to create an second network interface with a static private IP when building the instance to use as a internal(inside) interface for the UTM instance. My UTM, subnets and routing tables are all assigned to the same AZ. I have been able to configure an masquarade and some NAT rules. Then I am able to ssh using a different high port number for each of the Linux hosts through using UTM Outside interface EIP and high ssh port number. Also, can monitor the firewall log and see that its functioning correctly. 

Now the next question: Would it be best, just to spin up another UTM standalone instance within the Windows VPC and establish the two VPN connections from the Windows VPC?. I have realized that the HA-UTM model is fairly new and hasn't been used extensively yet from what I have been reading in this forum. And also, would it be possible to create a peering connect having just the Linux VPC and Windows VPC just in case their was a reason in the future that communication was needed between the Windows EC2 instances and Linux EC2 Instances.

Maybe the below scenario would work. VPC A would be my Windows VPC with two VPN connections and VPCB would be my Linux VPC. Each VPC would contain it's own Sophos UTM standalone instance.

Example: Edge to Edge Routing Through a VPN Connection or an AWS Direct Connect Connection

You have a VPC peering connection between VPC A and VPC B (pcx-aaaabbbb). VPC A also has a VPN connection or an AWS Direct Connect connection to a corporate network. Edge to edge routing is not supported; you cannot use VPC A to extend the peering relationship to exist between VPC B and the corporate network. For example, traffic from the corporate network can’t directly access VPC B by using the VPN connection or the AWS Direct Connect connection to VPC A.

From a cost perspective, it will be lower costs using the standalone model, however, with the UTM instance, subnets and routing tables all in the same AZ, possibly I can come up with a recovery scenario or in the future move to the HA-UTM model.

Any additional help and suggestions is highly appreciated,

Thanks,

Scott Spangler

DevOps Engineer