Now, more than ever, many of us need the flexibility to access data, files, and private applications whenever and wherever we’re able to get work done.
Cloud providers like Microsoft Azure give you the flexibility to make your move to the cloud as temporary or permanent as you need. And while this is the right time to provide users with secure virtual desktop services and extend on-premises resources to the cloud, it’s also paved the way for attackers to maliciously gain access to your company’s confidential cloud resources.
Simple to deploy
Sophos XG Firewall can easily be deployed from Azure Marketplace to secure access to services hosted in Azure.
A typical deployment of XG Firewall in Azure may look like this. In this example, XG Firewall is deployed in a Resource Group using the Azure Marketplace. The resource group consists of port A (internal interface of XG Firewall), port B (public interface of XG Firewall), XG Firewall virtual machine, disk associated with the virtual machine, a security group, and public IP.
- Ensure that a route table is created and is associated with the internal LAN. The route should be configured for all traffic, with the next hop as the XG Firewall’s LAN interface (Port A). This is required to route the traffic of the internal virtual machine via the XG Firewall interface.
- Important: Ensure that the internal virtual machine (server, in this example) is reachable to and from the XG Firewall.
- In this example, the virtual machine and XG Firewall are in the same subnet. However, if the internal resource has a subnet different from the internal interface of XG Firewall, ensure that a static route is created on the XG.
Greater visibility of network users and application using cloud resources
Once deployed, gaining visibility into network users and applications using cloud resources should be your first step, and it’s simple with XG Firewall’s web-based console and out-of-the-box comprehensive reports.
The administrator for XG Firewall in Azure has complete visibility of remote users in the cloud. The firewall logs and reports clearly demonstrate the footprints of a remote user, and in the case of a suspicious event, the administrator can easily disconnect the remote user at any given point.
Specific policies and quotas can even be applied to individual remote users or groups of users where necessary.
Simple, secure remote access with Sophos XG Firewall
VPN connections are crucial to enabling secure remote working. Sophos XG Firewall can easily be deployed from Azure Marketplace to secure access to services hosted in Azure with a range of VPN options.
Option 1: SSL VPN
The major challenge when working from home are various unforeseeable restrictions by internet service providers, as some block standard ports such as IPSEC port 500 and port 4500.
The SSL VPN in XG Firewall provides the option to use port 8443 or a custom port for connecting remote users to the cloud infrastructure.
- In Azure, ensure that the network security group associated with the public interface (Port B) of XG Firewall in Azure has a rule to allow inbound traffic for ports:
- 8443 – Default SSL VPN port, which can be customized from XG Firewall
- 443 – Default user portal, which can be customized from XG Firewall
- Port and IP on which the internal server is being accessed
- A rule to allow outbound traffic from the internal network
- A detailed description of the steps necessary to configure SSL VPN in XG Firewall is available here. This guide also provides the method for downloading the client configuration for a Windows workstation.
- To configure SSL VPN for Apple Mac workstations, please refer to this how-to guide.
- Important: The Azure Virtual Network NAT associates the private range IP associated with Port B with the remote user’s public IP. Hence, it becomes essential to enter the “Override hostname” in the field shown below with the Azure public IP. To enter the override hostname, navigate to CONFIGURE > VPN > Show VPN Settings > SSL VPN in the XG Firewall administrator console. This will ensure that when the user downloads the config file, they can connect to the XG Firewall in Azure on their public IP.
Option 2: Clientless VPN
A full tunnel configuration like SSL VPN allows remote users to upload and download content to and from the server. As this might prove to be a security concern for your organization, XG Firewall provides clientless VPN for more granular control. This option allows users to just view the contents of the internal resource without making any changes.
This configuration creates a bookmark on a permitted user’s XG Firewall user portal. The remote user logs into the user portal and clicks on the created bookmark to access the resource.
- In the Azure console, access to port 443 for user portal access (customizable) should be allowed for inbound traffic in the security group attached to port B (public interface).
- The bookmark on a permitted user’s XG Firewall user portal can be configured by following the steps in the how-to guide here.
- The bookmark can be accessed by navigating to the user portal as shown below.
Option 3: Sophos Remote Ethernet Device (SD RED)
The Sophos SD RED (Remote Ethernet Device) is a network device which connects remote offices over the public internet via a secure tunnel. SD RED provides a zero-touch deployment and ensures that the device is ready to connect to the Sophos XG Firewall in Azure as soon as it is plugged in by the remote user.
The configurations for the device are managed by the Sophos XG Firewall without requiring any prior knowledge of the remote office network. The SD RED device downloads its configuration from the provisioning server over the internet and securely connects to the internal resources protected by the XG Firewall in Azure.
This option is especially useful for users that require constant uninterrupted connections to the internal resources from their home offices. More information about the SD-RED models can be found here.
- The XG Firewall in Azure can be configured using this how-to guide.
- In the Azure console, ensure an inbound rule marked in the security group attached to port B (WAN interface for the XG) for allowing TCP 3400 and UDP 3410 to the XG Firewall public IP.
Option 4: Sophos Remote Ethernet Device (SD RED) site-to-site tunnel
In addition to traditional site-to-site IPSEC tunnels, a Sophos SD RED tunnel can be used to connect remote users to internal resources. The advantage here over the other forms of remote access is the simplicity, speed of communication, and ease of configuration.
The site-to-site SD RED connection is formed between the XG Firewall on premises and the XG Firewall in Azure. In this scenario, the SD RED creates a Layer 2 tunnel between the two XG Firewalls. This mode of communication also adds web and email protection for remote users as part of the subscription.
- A detailed description for configuring an on-premises XG Firewall as the SD RED client firewall and an XG Firewall in Azure as the SD RED server is available here.
- In the Azure console, ensure an inbound rule is marked in the security group attached to port B (WAN interface for XG Firewall) for allowing TCP 3400 and UDP 3410 to the XG Firewall public IP.
- Once configuration is complete, view the SD RED client and server firewall with the RED tunnel established in your XG Fireall console as shown below.
- XG Firewall Customer Resource Center (how-to videos, documentation, and more)
- XG Firewall How-To Video Library (dozens of video tutorials to get you started)
- XG Firewall Community (tap into the vast knowledge and expertise of the XG Firewall community)
Well written and done my friend!
I’ve only just begun blogging myself very recently and have seen
many writers merely rehash old content but add very little of
worth. It’s good to see an enlightening article of
some true value to myuself and your other followers.
It’s going onn the list of creteria I need to emulate being a new blogger.
Reader engagement and content quality are king.
Some excellent ideas; you have most certainly managed to
get oon my list of sites to follow!
Keep up the fantastic work!
All the best,