Disclaimer: This information is provided as-is without any guarantees. Please contact Sophos Professional Services if you require assistance with your specific environment.
This article describes how to implement a full Active/Active HA Sophos XG on Azure. The deployment makes use of the new Azure standard load balancer with its HA ports feature for outbound load distribution. Note:
Applies to the following Sophos products and versions Sophos Firewall
Log into the Azure Portal and open another browser tab to browse to the following URL: https://github.com/sophos-iaas/xg-azure-aa. Scroll down the page and click on the Deploy to Azure button. This will open up the template in the Azure portal. In the Custom deployment window, configure the following:
In the Terms and Conditions section, tick the checkbox to agree to the terms and click on Purchase
If the deployment is successful, you will be able to connect directly to the WebAdmin of each Sophos XG instance using TCP ports 4444, 4445, 4446 respectively. For example:
If the deployment is successful, you will be able to connect directly to the SSH of each Sophos XG instance using TCP ports 2222, 2223, 2224 respectively. For example:
Run the following command: ssh admin@<public IP> -p 2222 Enter yes when prompted regarding the authenticity of the host Enter the admin password when prompted
ssh admin@<public IP> -p 2222
In the console window, type 5 and press Enter to select Device Management Type 3 and press Enter to select Advanced Shell
Type the following command:
ip rule show
Verify that an ip rule exists that maps traffic between the XG’s LAN IP (10.42.2.5 in this example) and the Azure Magic IP (168.63.129.16) to route table (“lookup”) 200.
Next, type the following command to display the contents of table 200:
ip route show table 200
Verify that the default route matches the XG’s LAN adapter subnet gateway (by default this is the first IP address of the subnet in Azure, in our example this is 10.42.2.1).
Repeat the above steps for the remaining Sophos XG appliances. Remember to use the right SSH ports to connect to each of them.
The health probe status metric describes the health of the Sophos XG instances according to the load balancer health probe configuration. The Azure load balancer uses the status of the health probe to determine where to send new flows. Health probes originate from an Azure infrastructure address and are visible within the OS of the VM. Some reasons why health probes may fail include:
In the Azure Portal, go to Load balancers to select any of the load balancers that you want to verify. In the monitoring section, click on Metrics. In the Loadbalancer - Metrics window, select the Health Probe Status metric with Avg aggregation type. We can apply a filter on the required Backend IP address of the Sophos XG instances or port (or both). Note: The graph may fluctuate but this does not matter as long as the probe status does not get to 0 which is when it is removed from the pool of healthy instances.
Previous article ID: 133755
Hello,
is anybody able to explain work with Azure Magic IP 168.63.129.16 more detailed ?
I have redundant installation of two XGs in Azure and there are two load balancers - external and internal. External one is working because it gets response from firewall at the same interface where it receives requests from IP 168.63.129.16. It means at port B
But answers from internal LB (going to PortA) are going via port B. It does not work even If I allow answers without NAT and without blocking it (set advanced-firewall bypass-stateful-firewall-config).
Best regards,
Petr
Solved; conclusion is – firewall is answering to the same IP address (168.63.129.16) from inside and from outside IP. Outside answers are arranged by defaut route. Internal answers are arranged by policy based routing provided by operating system.
There is file customization_application_startup.sh in directory /scripts/system/clientpref/
/scripts/system/clientpref/customization_application_startup.sh
which contains startup script with lines like this :
ip route add default via 10.101.1.1 dev PortA table 200
ip rule add from 10.101.1.4 to 168.63.129.16 table 200
ip route flush cache
I met two cases caused problems :
First one – file mentioned above was empty
Second one – file contained bad IP address of nex hop. In place of 10.101.1.1, filled IP was from another, space which was not used in particular Azure environment (10.0.2.1).
And another one notice – if you change IP address of firewalls (use statically defined instead of dynamically assigned IPs), Azure will change its parameters, but you have to change parameters inside of Sophos XG route table manualy.
And last notice - you have to use this command :
mount -o remount,rw /
to unlock file for modification
I've been told this is going to be added into a future build where you will not have to do this. Didn't notice it in MR4 release notes so hopefully Sophos can comment on when this will not be required.
Also note that firmware updates will require you to rebuild the internal route tables. Sophos does have an automation file for it, but hopefully it will get rolled into the Azure builds so you don't have to mess with this.
Hi, I noticed that I had the same behaviour but even if i add the mentioned rroutes i still can't get the traffic flowing through the loadbalancer ip ( works for lan/wan private ips though ). Currently feels that I'm hitting a wall since i cant find a clear way to make XG18 work on Azure.
Hello, which protocol do you use for testing of XGs availability at loadbalancer ? I had problem with 4444 (do not know why; but I did not investigate it); I had to use proxy (3128).
If it will not solve you problem, list here content of file /scripts/system/clientpref/customization_application_startup.sh, internal IP of one XG and result of commands from the same XG :
...updates will require you to rebuild the internal route tables ... - I noticed it as well last weekend. I am going to raise it via support channel.