AU80 v17.5 To v18.0 XG Firewall Training Update

Sophos Delta Training
XG Firewall v18.0
Version 17.5 to 18.0
Hi there, this is the Sophos Delta training course for XG Firewall, from version 17.5 to v18.0.
Sophos Certified Delta

XG Firewall AU80 – XG Firewall v18.0 Delta Training
February 2020
Version: 18.0v1
Product version: 18.0
© 2020 Sophos Limited. All rights reserved. No part of this document may be used or reproduced in
any form or by any means without the prior written consent of Sophos.
Sophos and the Sophos logo are registered trademarks of Sophos Limited. Other names, logos and
marks mentioned in this document may be the trademarks or registered trademarks of Sophos
Limited or their respective owners.
While reasonable care has been taken in the preparation of this document, Sophos makes no
warranties, conditions or representations (whether express or implied) as to its completeness or
accuracy. This document is subject to change at any time without notice.
Sophos Limited is a company registered in England number 2096520, whose registered office is at
The Pentagon, Abingdon Science Park, Abingdon, Oxfordshire, OX14 3YP.
Sophos XG Firewall v18.0 Architect Delta - 1

About This Course
This course will cover the changes between XG Firewall version 17.5 and
version 18.0, and is required to maintain your certificate
Course Duration This course will take around 45 minutes to complete
Certified in XG Firewall Architect and any subsequent delta

Prerequisites modules up to version 17.5
This 45 minutes course will cover the changes between XG Firewall version 17.5 and version 18.0,
and is required to maintain your certificate.
Prior to taking this training you should have completed and passed the Sophos XG Firewall Certified
Architect course and any subsequent delta modules up to version 17.5

Glossary of Technical Terms
A glossary of technical terms used throughout the course

can be found in knowledgebase article 118500
https://sophos.com/kb/118500
A glossary of technical terms used throughout the course can be found in knowledge base article
118500.

Additional Information
Additional information When you see this icon you can find
in the notes additional information in the notes of the
student handout
When you see this icon you can find additional information in the notes of the student handout.

TRAINING FEEDBACK
Feedback is always welcome

Please email globaltraining@sophos.com
Feedback on our courses is always welcome.
Please email us at globaltraining@sophos.com with your comments.

XG Firewall v17.5 to v18.0
Web Protection
• Deploying XG Firewall for Web Protection
• Configuring Web Protection
• TLS Decryption
Public Cloud
• XG on Azure overview and basic deployment
• Azure deployment scenarios
• High Availability on Azure
This course will cover the changes to the XG Firewall Architect course.
We will cover deploying and configuring Web Protection on XG Firewall and TLS decryption. We will
also cover how XG Firewall can be deployed on Azure to protect systems and services running on
public cloud infrastructure. In this course, you will learn how to deploy XG Firewall on Azure, and
where it sits in a standard Azure infrastructure.

Web Protection
Web Protection

Deploying XG Firewall for Web Protection
Gateway or mixed mode deployments

Web Protection
LAN Zone WAN Zone
Internet
XG Firewall
Filter web traffic
The XG Firewall is often deployed to provide web protection to networks. Over the next few slides
we will look at different ways this can be implemented.
If the XG Firewall is the network gateway, or will be replacing an existing gateway then web filtering
can simply be enabled for the traffic passing through it.
This deployment scenario is ideal as all traffic must pass through the XG firewall before being
allowed out to the internet. As such, all traffic entering the network must also pass through the XG
Firewall before reaching clients. By implementing in this fashion, all web traffic can be scanned,
decrypted, sent to sandstorm (if needed), and controlled so that users cannot violate company
policy and hackers cannot pass unseen.
In this deployment scenario, the XG can be used as both a transparent and explicit proxy.

Bridge mode deployments

Web Protection
Internet
XG Firewall Firewall
Transparently filter
web traffic Other networks such
as DMZ will not be
filtered
In scenarios where the XG Firewall will not be the primary network gateway there are two
deployment options.
The first is to add XG Firewall to the network in bridge mode, allowing it to transparently filter the
web traffic. This is a great solution if the existing edge device will not be replaced. Similarly to the
previous solution, anyone behind the XG firewall will not be able to bypass the filter and will have
their traffic inspected. The only exception would be if there were another network, such as a DMZ
hosting some public servers, hanging off of the edge firewall.

Explicit proxy deployments

Web Protection
Switch
Internet
Firewall
Configure clients to
use XG Firewall as Allow web traffic
web proxy from XG Firewall
only
XG Firewall
The other option is for the XG Firewall to be on the network but not in the direct flow of traffic, and
have the clients configured to use it as an explicit proxy.
In this configuration, the XG Firewall doesn’t have any control over traffic that is sent directly to the
default gateway, and so it is important that the edge device is configured to only allow web traffic
from allowed devices, including the XG Firewall.

Transparent vs. Explicit Proxy
Transparent Explicit
Web Protection
Typically deployed at the gateway

Requires client (operating
Does not require client configuration system/browser/application) to be
configured with the proxy details
Client (operating
system/browser/application) is unaware Firewall must be configured to only
the traffic is being filtered allow web traffic from proxy to prevent
users circumventing it
Users cannot circumvent the filtering
In these examples, we have assumed that transparent filtering will be used, except in the case of
explicit proxy deployment.
XG Firewall supports dual transparent and explicit proxy web filtering for gateway and mixed mode
deployments.
The key differences between transparent and explicit proxy web filtering are:
In an explicit proxy configuration, the client (e.g. browser, desktop application, etc.) is explicitly
configured to use a proxy server, meaning the client knows that all requests will go through a proxy.
The client is given the hostname/IP address and port number of the proxy service. When a user
makes a request, the client connects to the proxy service and sends the request. The disadvantage
of explicit proxy is that each client must be properly configured to use the proxy.
In a transparent proxy configuration, the proxy is typically deployed at the Internet gateway and the
proxy service is configured to intercept traffic for a specified port. The client (e.g. browser, desktop
application etc.) is unaware that traffic is being processed by a proxy. For example, a transparent
HTTP proxy is configured to intercept all traffic on port 80/443. The typical benefits of a transparent
proxy include a standard enterprise configuration where all clients routed to the internet will always
be filtered and protected no matter what the end users do, or change, on their machines and the
added benefit of reduction in typical user’s client-proxy configuration troubleshooting. Transparent
proxy’s also handle mobile and guest devices without any additional configuration.

Additional information
in the notes
DPI Engine vs. Web Proxy
DPI Engine Web Proxy
Ports Any 80 & 443 only
FastPath Support Yes No

Web Protection
Policy-driven, TLS
Decryption Port 80 & 443
(including support for TLS 1.3)
SafeSearch Enforcement No * Yes
YouTube Restrictions No Yes
Explicit Proxy No Yes
Content caching No Yes
Parent Proxy No Yes

* There is an alternative method for enforcing SafeSearch using DNS
XG Firewall v18.0 introduced a new DPI (deep packet inspection) engine that can perform port
agnostic web filtering, however, the legacy web proxy has been retained for some use cases. Let’s
take a moment to consider why you might choose one over the other.
You may want to use the legacy web proxy to enforce SafeSearch or YouTube restrictions, or because
your clients are configured to use the XG Firewall as an explicit proxy.
As we mentioned, the DPI engine can protect HTTP and HTTPS traffic on any port using protocol
detection, and most importantly for performance, it can make use of FastPath offloading.
Note that there is an alternative method for enforcing SafeSearch using DNS. Details can be found in
the handout notes.
https://support.opendns.com/hc/en-us/articles/227986807-How-to-Enforcing-Google-SafeSearch-
YouTube-and-Bing

DPI Filtering
Web Protection
Decrypt Web Content

sophos.com on port 80 HTTPS Policy Scan
sophos.com on port 443 Web Proxy

Firewall
sophos.com on port 8080

SSL/TLS Web Content App
IPS
Rules Policy Scan Control
DPI Engine
FastPath
Let’s look at how the configuration in the firewall rules affects how web traffic is processed.
Using the configuration shown here, all of the traffic will be handled by the DPI engine for IPS and
proxy-less web filtering and SSL decryption on any port for HTTP and HTTPS using port agnostic
protocol identification.
In this configuration, the SSL/TLS inspection rules are used to manage the decryption of secure web
traffic.
Using the DPI engine allows the XG Firewall to offload safe traffic to the FastPath. This is done for
traffic that the XG Firewall qualifies as being safe, or that matches identities for SophosLabs trusted
traffic.
Later in this module we will cover the configuration, requirements and managing exclusions for TLS.

Web Proxy Filtering
Web Protection
Decrypt Web Content

sophos.com on port 80 HTTPS Policy Scan
sophos.com on port 443 Web Proxy

Firewall
sophos.com on port 8080

SSL/TLS Web Content App
IPS
Rules Policy Scan Control
DPI Engine
FastPath
If you enable the web proxy, then HTTP and HTTPS traffic on ports 80 and 443 will be processed by
the legacy web proxy for decryption, web policy, and content scanning before being handed to the
DPI engine for application control and IPS.
HTTP or HTTPS traffic on other ports will still be handled by the DPI engine.
The legacy web proxy is also used in explicit proxy configurations.
When the web proxy is being used none of the traffic can be offloaded to the FastPath. This includes
any traffic that matches identities for SophosLabs trusted traffic.

Configuration Review
Dynamic Categories
User Activities
Categories
Web Protection
URL Groups
Users &
Groups File Types Constraints
Content Filter Action Status
Web policies comprise an ordered list of rules and a default action, either allow or deny, that
determines the behavior if the traffic does not match any of the rules.
Each web policy rule applies to either specific users and groups, or everyone.
You define the activities, or types of web traffic that are going to be controlled by the rule, and you
can optionally also apply a keyword content filter to the traffic.
Each rule has an action, allow, warn, quota or block, and this can be overridden so there is a
separate action applied to HTTPS traffic.
You can set time constraints for the rule. If no time constraints are selected then the rule will be
active all of the time.
Finally, you can enable and disable individual rules – don’t forget to turn rules on when you create
them!

Web Policies
Web Protection
Below the web policy rules are further options, some of which require the web proxy to be
enforced, these are indicated with a notice. If these options are selected and used with the DPI
engine they will not be enforced.
The available options are:

• Enforce SafeSearch in common search engines. This is done by modifying the request to enable
the features in the search engine and requires decrypting the web traffic
• Enforce YouTube restrictions, which is done in the same way as enforcing SafeSearch
• Configure how much quota time users have per day. We will cover this in more detail later in the
module
• Control advanced settings such as logging, file size limits and access to Google apps

Web Policies
Web Protection
If there are options that cannot be enforced this will be indicated in the firewall rule.

Web Proxy Content Caching
Web Protection
The XG Firewall can be configured to cache web content, which can save bandwidth for sites with
limited or slower internet access, however, this requires the web proxy to enforce.
The option to cache Sophos endpoint updates is useful if you are also running Sophos Central Server
or Endpoint protection. This will allow the XG Firewall to cache updates the first time a client
requests them from the Sophos warehouse. The next client that requests the update will then be
passed the files from the XG and will not have to download them from Sophos again. In medium to
larger environments that do not use Sophos Update Caches, this is a very valuable option to save
Internet bandwidth.

TLS Decryption
80% 25%
Web Protection
of traffic is encrypted
96% of malware calling HTTPS URLs
32% 28%
are not decrypting SSL

of malware download via TLS of PUAs using TLS
Data from SophosLabs for the first 8 months of 2019
TLS decryption is not solely for web protection as all network traffic should be decrypted to allow
proper inspection, however web protection is an area where it is most commonly used.
Why is it so important?
• 80% of traffic is encrypted

• 32% of malware is downloaded via TLS
• 25% of malware is calling out to HTTPS URLs
• 28% of PUAs are using TLS
Despite this, 96% are not decrypting SSL! This is a huge vulnerability.
Reference:
This data is based on telemetry from Sophos products and is provided from SophosLabs for the first
8 months of 2019.

Configuration
Inspection Rules
Web Protection
The main configuration element are the SSL/TLS inspection rules that define what to decrypt.
Not all SSL traffic can or should be treated the same it’s a balancing act of security, compliance,
privacy, and performance. With this in mind, flexibility is essential, and so the inspection rules
provide a granular selection of:
• Source, using zones, networks and users and groups
• Destination, using zones, networks, and services
• Applications
• Websites and categories
• Cipher algorithms

Configuration
Inspection Settings
Web Protection
The SSL/TLS inspection settings can be opened from the inspection rules page, and define the global
configuration.
These settings cover:

• The certificate authorities to use for signing certificates
• How to handle non-decryptable traffic
• TLS 1.3 compatibility

Configuration
Decryption Profiles
Web Protection
Decrypt profiles are managed in SYSTEM > Profiles > Decryption profiles, and they override and
extend the global settings.
There are three default profiles out-of-the-box that cover:

• Maximum compatibility, but lowest security
• Block insecure SSL, which should work in most cases
• Strict compliance, to help drive towards meeting compliance standards
You can also create custom profiles. In them you can:

• Override the resigning certificate authorities
• Override how non-decryptable traffic is handled
• Manage specific certificate, protocol and cipher enforcement settings

Legacy Web Proxy Decryption Settings
Web Protection
When using the legacy web proxy the decryption settings are configured in PROTECT > Web >
General settings.
There is a more limited set of options, but you can:

• Select the resigning certificate authority
• Block invalid SSL protocols and certificates
• Select how to handle errors

Managing TLS Exceptions
Web Protection
Administrator
maintained
exclusion list
Sophos
maintained
exclusion list
When working with the web proxy and decrypting HTTPS, there are times when you do not want to
decrypt certain sites. There are a number of reasons that this may be true. For example:
• Some sites check the certificates and if they find that the XG is intercepting communication (this
looks like a man-in-the-middle attack) then the website will reject the connection to the client
• There are other times when you only want to decrypt a certain set of websites and allow
everything else to pass through unhindered. This is often done for speed or to lower resource
utilization on the firewall
Sophos maintains a list known sites that are not compatible with TLS decryption, which is updated
as part of the XG Firewalls update process and automatically applied to web policies. This is known
as the Managed TLS exclusion list.
Additionally, there is a Local TLS exclusion list that, by default, is empty. This list exists for admins to
add sites that they want to exempt from TLS decryption. There is already a built-in rule that applies
to web policy so all an admin would need to do is add sites to the list.

Web Protection
It is also possible to add domains to the TLS Exceptions on the fly. From the Control Center click on
the SSL/TLS connections widget.

Tale action to
resolve errors
TLS decryption
Web Protection
errors
Chart of firewall
sessions including
decryption limit
This page displays a list of TLS decryption errors in the past 7 days, as well as a chart that shows the
firewall sessions along with the SSL/TLS decryption limit.
Note that every device has a decryption limit that is based on its specification, this cannot be
changed.
In the top-right of the TLS decryption errors table is a link to help you take action to resolve them.

Web Protection
Adds domain to Local

TLS Exclusions URL
group
Here you can see the list of applications that have TLS errors. By selecting an application on the left
you can see details of the errors and the users affected. At the bottom, you can choose to hide the
application from the error list or exclude it from decryption. This will add it to the Local TLS
Exclusions URL group.

Legacy HTTPS exceptions
Web Protection
For the legacy web proxy, exceptions are configuring in PROTECT > Web > Exceptions.
Exceptions can be matched on:

• URL patterns
• Web site categories
• Source and destination IP addresses
You can choose to skip:

• HTTPS decryption or certificate validation
• Malware and content scanning
• Sandstorm
• Policy checks

Certificates
SSL CA certificates must be deployed to clients

Web Protection
If different certificates are selected in certain profiles these will also need to be
deployed to endpoints
In a Windows domain this can be done using Active Directory Group Policy
Although browsers generally used the operating system CA store other applications
may not
To be able to use TLS inspection successfully you need to understand the requirements around
certificates, and the potential issues you can come across.
Deployment of SSL/TLS signing certificates is required for decrypted connections to be trusted by

endpoint devices.
Copies of the re-signing certificates configured for use in Rules and policies > SSL/TLS inspection
rules > SSL/TLS inspection settings should be installed on all endpoints whose traffic is to be
decrypted. Failure to do so will result in browsers displaying certificate warnings and potentially
preventing access to some sites.
If you configure different re-signing certificates to use for certain profiles, copies of those certificates
will need to be deployed to endpoints whose traffic is impacted by those profiles.
Certificates can be deployed to managed Windows endpoints using Active Directory GPOs.
Even so, not all applications running on endpoints will trust the added certificates.
Although browsers will generally trust additional CAs, other applications may be written or
configured to be more strict about checking the certificates or may use their own certificate stores.
Where an application uses its own certificate store it may not be easy, or even possible, to update it
other than by the publishers.

Certificate Pinning
Some applications make use of certificate pinning

Web Protection
Checking for a known certificate or public key associated with the host
Exclusions need to be created for traffic that uses pinned certificates
XG Firewall is preconfigured with exclusions for domains associates with applications

that do not support SSL inspection
Some applications may use certificate pinning, where they check for specific known certificates or
that the certificate presented by the server is signed by a specific certificate authority.
When enabling SSL inspection for a wide range of destinations and ports, some applications may
experience difficulties. You will need to create rules or modify existing rules to exclude such traffic
from decryption.
XG Firewall includes a range of exclusions for domains that we know to be associated with
applications that do not respond well to SSL inspection.

Certificates on Mobile Devices
CA certificates can be installed on iOS and Android (7.0 and later)

Web Protection
CA certificates are generally added to a local user or user CA list
Many apps are not built to include the user CA chain
You can install the CA certificate on iOS and Android mobile devices (Android 7.0 and later).
However, the CA is treated differently than the system's built-in root CA certificates, and is added to
a local or user CA list. Apps generally have to be built to specifically include the user CA chain and
many popular Apps are not, which means that they cannot work with SSL/TLS decryption.

SSL VPNs
Exclude the VPN hostname in the

Local TLS exclusion list
Web Protection
The VPN client application in a don’t decrypt inspection rule
The destination IP addresses in a don’t decrypt inspection rule
SSL VPN client apps, such as Cisco's AnyConnect, are known to fail when their SSL/TLS connections
are being decrypted. When users behind a firewall are expected to connect to VPNs over SSL/TLS the
destinations should be excluded. You can do this by adding the VPN hostname to the 'Local TLS
exclusion list' URL group, or by creating a new SSL/TLS inspection rule set to 'Do not decrypt' for the
destination IP addresses of the VPN servers.

Certificate Key Types
XG Firewall can create and use RSA or elliptic curve certificates
XG Firewall matches the certificate types to the original server certificate

Web Protection
In most scenarios it is not necessary to provide both types of certificate
When creating CSRs for resigning CAs

or WebAdmin server certificate we
recommend selecting either secp256r1
or secp384r1
XG Firewall can create and use RSA or Elliptic Curve certificates. When configuring SSL/TLS
inspection, you can specify two different signing CAs. Which one is used depends on the type of
certificate used to sign the original server certificate.
In most situations, it is not necessary to provide both an RSA and an Elliptic Curve. All browsers and
most other applications can handle both types of cryptographic algorithms and the protocols
generally support the mixing of key types in certificate signing chains. However, there may be some
situations where legacy or poorly-implemented applications cannot handle the mixing of algorithm
types. This is why we allow you to choose to specify different re-signing CAs.
Please note that although XG Firewall supports creating CSRs and certificates using three different
Elliptic Curve parameters, only two are supported by all browsers. When creating CSRs for use as re-
signing CAs, or as the server certificate for the WebAdmin, we recommend to select only one of the
following:
• secp256r1 (also known as prime256v1)
• secp384r1
Don't forget that if you choose to use two different re-signing CAs you will need to ensure that both
are deployed to and trusted by all endpoints.

Public Cloud
Public Cloud

Public Cloud Shared Security Model
Responsibility On-Premise IaaS PaaS SaaS
Data classification & accountability
Client & endpoint protection

Public Cloud
Identity & access management
Application level controls
Network controls
Key
Cloud customer Host infrastructure
Cloud provider
Physical security
Source: Microsoft TechNet – Shared Responsibilities for Cloud Computing
As organizations consider and evaluate public cloud services, it is essential to explore how different
cloud service models will affect cost, ease of use, privacy, security and compliance. It is equally
important that customers consider how security and compliance are managed by the cloud solution
provider (CSP) who will enable a safe computing solution. In addition, many organizations that
consider public cloud computing mistakenly assume that after moving to the cloud their role in
securing their data shifts most security and compliance responsibilities to the CSP. Cloud providers
by design should provide security for certain elements, such as the physical infrastructure and
network elements, but customers must be aware of their own responsibilities. CSPs may provide
services to help protect data, but customers must also understand their role in protecting the
security and privacy of their data. The best illustration of this issue involves the poor
implementation of a password policy; a CSP’s best security measures will be defeated if users fail to
use complex or difficult-to-guess passwords.

Sophos XG Firewall on Azure - Licensing
PAYG BYOL
Pay-As-You-Go Bring Your Own License
You will incur a charge for: You will incur a charge for:
Public Cloud
Time you spend running XG Firewall on Hourly pricing of the VM you selected to
Azure. power the Sophos XG Firewall on Azure
software.
Hourly pricing of the VM you selected to
power the Sophos XG Firewall on Azure
software.
http://sophos.com/medialibrary/PDFs/other/Virtual-Machines-Sizing.pdf
You can purchase Sophos XG Firewall as a pre-configured virtual machine (VM) image. VM images
are available from the Azure Marketplace. VMs come in a variety of types and sizes, similar to
selecting different option sizes for hardware appliances in the on-premises world. You can launch
and use XG Firewall on Azure, and either pay-as-you-go or you can bring your own license (BYOL).
Launch XG Firewall on Azure and pay only for what you use, when you use it. No upfront
commitment. No minimum fee. And you can delete your XG Firewall at any time.
Seasonal compute workloads that often experience high utilization during peak times of the year,
but low utilization during off-peak times (such as tax or retail websites), may find PAYG
advantageous. You can scale the capacity of your XG Firewall up or down as needed while paying
only for what you use.
When you PAYG, XG Firewall comes preconfigured with FullGuard, meaning your XG Firewall solution
is enabled with all available security modules, including Network Protection, Web Protection, and
more. If Enhanced Plus Support is desired, please consider BYOL, as described below.
When you BYOL, you bring a standard XG Firewall software license that you purchased from an
authorized Sophos reseller. These licenses are configurable. You can select a term of one, two, or
three years. You can also select any number of software subscriptions, including Network Protection,
Web Protection, and Sandstorm.
You will not be charged again for the license you bring, but your license is required in order to
benefit from your entitlements.
https://www.sophos.com/medialibrary/PDFs/other/Virtual-Machines-Sizing.pdf

Sophos XG Azure VM Size Alignment
Hourly cost depends on VM size
Virtual licenses depend on RAM and CPU resources
We recommend using the Fv2-Series VMs which are designed for NVAs
Public Cloud
https://docs.microsoft.com/azure/virtual-
https://azure.microsoft.com/pricing/calculator/
machines/windows/sizes-compute
VM sized determines the

maximum number of NICs
The hourly cost depends on the VM size you select, and the virtual licenses depend the RAM and
CPU resources.
The following VM types are most aligned with our virtual license SKUs:
• F-Series
• Fv2-Series
• Av2-Series
The F-Series and Fv2-Series are the series that Microsoft designed for NVAs (Network Virtual
Appliances) like our Sophos XG Firewall. We recommend using the Fv2-Series VMs..
Note that the VM size you select also determines the maximum number if NICs (network interface
cards) that you can use.
https://azure.microsoft.com/pricing/calculator/
https://docs.microsoft.com/azure/virtual-machines/windows/sizes-compute

Management Options and Considerations
Bring Your Own License Pay As You Go Managed Service Provider
Individual Firewall
Management
SFM (Nested Virtualization

Public Cloud
in Azure)
SFM (Deployed on
Premise)
SCFM (Partners Only)
Central Firewall
Management
XML API
There are different options for managing multiple Sophos XG firewalls in Azure. The licensing
method of the XG Firewalls determines which options are possible.
For example, SCFM can't be used to manage PAYG deployments as PAYG appliances are not
registered in My Sophos.

XG Firewall on Azure
Cloud Access
Tier
Public Cloud
Security Tier
Identity Tier
App & Data

Tier
Over the next few slides we look at how XG Firewall can be used to improve the security of Azure
deployments.
Let’s start by looking at Azure architecture.
We can start with a four tier model, much like every other best practive design in Azure; this is made
up of a Cloud Access tier, a Security tier, an Identity tier and an App and Data tier.
Here we have arranged them from top to bottom, however these tiers can be thought of as building
blocks that can be modelled in whatever layout makes sense to you. What is important is that you
need all four functions represented by these tiers to build a secure and resilient cloud solution.

XG Firewall on Azure
Cloud Access
Tier Traffic Manager Network Security Groups
VNet
subnet
Public Cloud
Security Tier
subnet
Identity Tier
subnet
subnet
App & Data
subnet
Tier Virtual Machines Worker Roles Web Roles Cloud Services
Let’s add a virtual network (VNet) to our architecture. Azure Virtual Networks are used to connect
Azure resources to each other and allow for network seperation.
We can also add subnets to our diagram. In this example we are hosting all of the tiers and subnets
in the same VNet, however, you can choose to seperate the tiers into different Vnets and have as
many (or as few) subnets per VNet as you like.
Next we will populate the App and Data tier with some virtual machines, worker roles, web roles,
and whatever else your typical Azure deployment may contain.
In the Cloud Access tier we will add a Network Security Group, which can be used to limit network
traffic to resources in a virtual network. We have a single Network Security Group in this simple
example, but other deployments may make use of multiple Network Security Groups.
If you have a particularly popular or data intensive app, you can also add a Traffic Manager for Geo
load balancing, addressing the availability aspects of a typical Azure design.
This architecture now represents a typical Cloud deployment; several services sitting behind a
Network Security Group in a VNet. Looking at the tiered model the way it is represented here you
can immediately see that neither the Identity or Security tiers are being used, and this is where the
XG Firewall will operate.

XG Firewall on Azure Internet
Cloud Access
VNet
subnet
Public Cloud
Security Tier
XG Firewall
subnet
VM
Identity Tier
Active Directory
subnet
subnet
App & Data
subnet
Network Security Groups are powerful stateful firewalls that will scale to meet the required load,
they lack many features modern firewalls offer such as Intrusion Prevention, Advanced Threat
Detection and Application Control. They also lack a built in centralized reporting and logging facility,
although these can be built using Microsoft Operations Management Suite or Security Center, which
leaves both a security and visibility blind spot in your architecture.
First, we can add Azure or Server AD to the Identity tier and start enforcing authentication for your
critical App and Data tier services.
Then we can add a Sophos XG Firewall to provide in depth packet inspection, IPS, ATP, Web
Application Firewalling and outbound Web Filtering.
Now that we have the basics of every tier covered, we can safely send and receive traffic to and
from the Internet, with the XG Firewall processing both inbound and outbound traffic.
Now that traffic from and to the internet is secure, let’s leverage the Traffic Manager we placed in
the model earlier to perform Geo Loadbalancing like before, but instead of sending it to the backend
servers, let’s balance traffic for each site to the XG Firewall.
And of course, the XG Firewall supports Active Directory authentication for both inbound and
outbound traffic, requiring users to authenticate either transparently (outbound) or explicitly
(inbound) before they can access the protected backend services.

XG Firewall on Azure Internet
Cloud Access
On premise infrastructure
VNet
VPN Gateway ExpressRoute
subnet
Public Cloud
Security Tier
XG Firewall
subnet
VM
Identity Tier
Active Directory
subnet
subnet
App & Data
subnet
So what about connections to external sites such as the corporate backoffice that is still on premise?
The traffic can be routed from your existing ExpressRoute or VPN Gateway to the XG Firewall as a
next hop for the internal networks, or you can replace their functionality with XG Firewall’s native
IPsec, SSL or RED layer 2 VPN technologies.
Now traffic flowing between your on-premise and Azure infrastructure is subject to filtering, and
ensures that neither site can be used as a weapon against the other.
Using the XG Firewall to protect Azure infrastructure in this way also comes with the benefit of on-
box logging and reporting without the need for additional tools.

Deployment
Open
Public Cloud
Configure
Deploy XG Internet
Routing in
Firewall Ports in
Azure
Azure
Continue
We will consider the deployment of XG Firewall on Azure as being in broadly three phases:
Deploying the XG Firewall from the Azure Marketplace, either through the Azure portal or using
ARM scripts
Configuring the necessary routing in Azure
Opening the required Internet ports in Azure
Click each topic to view that section, then click Continue when you are ready to proceed.

Deploy XG Firewall
Public Cloud
Deploy XG
Firewall

Sophos XG Firewall In Azure Deployment Overview
Public Cloud
Search for XG
Complete the Connect to the
Firewall in the Obtain the public
necessary WebAdmin and
Azure Marketplace IP address of the
parameters to complete the initial
and select to XG Firewall
deploy XG Firewall configuration
deploy it
We will start by looking at how to deploy an XG Firewall through the Azure portal. This is a realtively
simple process that consists of:
• Searching for XG Firewall in the Azure Marketplace and selecting to deploy it
• Complete the necessary parameters for the deployment, this includes:
• License type – bring-your-own or pay-as-you-go
• Virtual machine size
• Subnets
• IP and hostname
• Storage
• Once the XG Firewall is deploed, you will need to obtain the public IP address from the Azure
portal
• Login to the WebAdmin to complete the initial configuration of the XG Firewall

Deploy an XG Firewall on Azure
Public Cloud
This simulation will guide you through deploying an XG Firewall on Azure.
Follow the instructions to advance to the next step
Start
Let’s look at how all of this works with a simulation. This simulation will guide you through deploying
an XG Firewall on Azure.
Review the information at each stage, and then follow the instructions to advance to the next step.

Use the search box at the top of the page to search for XG Firewall then press Enter to continue
Simulation

Select Sophos XG Firewall from the results
Simulation

Click Create
Simulation

In the ‘VM Name’ field enter XGFirewall
Enter and confirm the password Sophos1985
Simulation
We will use the currently selected subscription. Below the ‘Resource group’ field click Create new

In the ‘Name’ field enter xgdemo
Simulation
Click OK

We will use the currently selected Azure region
Simulation
Click OK

We will use the BYOL license type and the default virtual machine size, but you can change these to meet your needs
Simulation
Click Configure subnets

We will use the default auto-populated options but you can change these to suit your environment
Simulation
Click OK

In the ‘Domain name’ field, enter xgdemo as the public hostname for this deployment
Simulation
In the ‘Storage Account’ filed, click Configure required settings

In the ‘Name’ field, enter sophosxgdemowesteu
Simulation
Click OK

Review your settings then click OK
Simulation

Azure will validate your options, this can take several minutes depending on the region
Simulation
Click OK

Click Create
Simulation

Click Deployment in progress in the top-right
Simulation

The deployment may take several minutes to complete
Simulation
Click Go To resource

Click the XGFirewall virtual machine
Simulation

Here you can view the virtual machine details, including the IP address and DNS name
Simulation
Open a new tab by clicking +

In the address bar enter https://xgdemo.westeurope.cloudapp.azure.com:4444 then press Enter
Simulation

Login as admin with the password Sophos1985, you set this during the deployment
Simulation

Read the license agreement then click I accept
Simulation

If you have a serial number you would enter it here
Simulation
Select I don’t have a serial number (start a trial)

Click Continue
Simulation

Click Sign In
Simulation

Sign In with the email address xg@sophostraining.xyz and the password Sophos1985
Simulation

You would need to complete the reCAPTCHA
Simulation
Click Continue

Click Confirm Registration + Evaluation License
Simulation

Click Initiate License Synchronization
Simulation

Click Continue
Simulation

You will then have access to the WebAdmin to complete the configuration of the XG Firewall
Simulation

You will then have access to the WebAdmin to complete the configuration of the XG Firewall
Simulation
Continue

in the notes
XG Firewall ARM Templates
• Azure Resource Manager (ARM) templates available from our GitHub
repository
o https://github.com/sophos-iaas/xg-azure
Public Cloud
Sophos has created Azure Resource Manager (ARM) templates that can be used to deploy XG
Firewall on Azure, and use Azure Load Balancer Probes to determine the health status of XG
Firewall, and automatically failover when needed. These can be downloaded from Sophos’ GitHub
repository.
[Additional Information]
• Sign in to the Azure portal
https://portal.azure.com
• Browse to the Sophos github page
https://github.com/sophos-iaas/xg-azure
• In the README.md section, click on the Deploy to Azure option. This will automatically open the
template deployment on Azure

Deploy an ARM Template
Public Cloud
Complete the parameters for the template then click Purchase.
The fields are defined in the ARM template along with default values where applicable and select
fields where the allowed values are limited.
A parameters files can be used to provide all of the values for the ARM template so that they can be
scripted without interaction. This allows ARM templates to be used for automation.
You can download and customize the ARM templates provided by Sophos before using them.

Configure Routing in Azure
Public Cloud
Configure
Routing in
Azure

Default Outbound Traffic Flow
• Virtual networks in Azure have

outbound Internet connectivity Internet Gateway
through an Azure managed
Internet gateway by default
Public Cloud
vNet: Prod
• Subnets in Azure have system Address space: 10.0.0.0/16
routes to route traffic inside the
vNET and send Internet traffic to
the Azure managed Internet 10.0.0.1 10.0.1.1
gateway
Type Destination Next Hop Type
System 10.0.0.0/16 Virtual Network
VM VM VM
System 0.0.0.0/0 Internet
10.0.0.0/24 10.0.1.0/24
Microsoft has designed Azure virtual networking with connectivity in mind. As a result, all vNETs are
deployed with an Azure managed Internet gateway by default.
Subnets inside the vNET will use the so-called system routes if no other route table is present, to
allow the VMs to communicate with each other and send traffic to the internet through the Azure
managed gateway.
Because the system routes are applied at a platform level they will take precedence over locally
configured routes on the VMs, even inside a subnet.
If, for example, the default gateway on a VM is different from the one configured at the platform
level Azure will route the traffic to the vNets default gateway instead.

in the notes
Default Outbound Traffic Flow
• We cannot delete system routes

but we can override them using Internet Gateway
user-defined routes
Public Cloud
• To benefit from the advanced vNet: Prod

security features of the Sophos XG Address space: 10.0.0.0/16
firewall, internet bound traffic will
need to be routed to the firewall
10.0.0.1 10.0.1.1 10.0.2.1
Type Destination Next Hop Type Next Hop

System 10.0.0.0/16 Virtual Network XG
VM VM VM 10.0.2.5
User Defined 0.0.0.0/0 Virtual Appliance 10.0.2.5
10.0.0.0/24 10.0.1.0/24 10.0.2.0/24
Since system routes cannot be deleted, the only way to override the routing behavior of Azure is to
create a user defined route table entry that replaces the system route.
In our case, this means that in order for your Azure environment to benefit from the added security
offered by the XG Firewall, you will need to configure a user defined default route that points traffic
destined for the internet at the XG’s LAN interface.
For more information about user defined routes see:
https://docs.microsoft.com/azure/virtual-network/virtual-networks-udr-overview

Sophos XG Firewall In Azure Deployment Overview
Public Cloud
Create and Configure routing

Obtain the private configure a custom on the Sophos XG
IP of the LAN NIC route table and firewall to send
of the XG Firewall attach it to the return traffic out
backend subnet the LAN interface
To demonstrate how routing in Azure works, we’ll deploy a new subnet with a new VM.
We will obtain the private IP address of our XG’s LAN interface, then configure a user defined route
and attach it to the new subnet.
We’ll finish by setting up our XG Firewall to return the traffic to the correct backend subnet through
it’s LAN interface.

Virtual Machines > XG Firewall > Networking > PortA
Obtain the LAN IP Address
Public Cloud
With the new VM deployed, the next step is to configure the User Defined Route table (or UDR for
short) in Azure.
To do this, we’ll first need to find the private IP address of the XG Firewall’s LAN adapter.
There are two ways to go about this: You can log in to WebAdmin and look up the interface IP on the
Interfaces tab of the Network menu, or we can look it up through the Azure Portal by opening the
Virtual Machine blade, selecting the XG Firewall VM and then selecting the Networking menu.
The advantage to doing it this way is that we have the option to edit the LAN interface (which should
be PortA by default) and modify the IP address on the interface to become static instead of
dynamically assigned.

Create a User Defined Route Table
Public Cloud
Now that we know the private IP address of the XG Firewall’s LAN adapter, we can go ahead and
create a new defined route table.
To do this, search for “Route tables” in the Azure portal.

Public Cloud
To create the route table, give it a descriptive name so you know what it is for, then configure the
subscription, resource group and location as you would normally.

Public Cloud
Once Azure finishes deploying the new route table, you need to open it and start adding routes.
Set a name for the route, the destination prefix, which is 0.0.0.0/0 in our example as we are defining
a default gateway.
Select the next hop type, a virtual appliance in the case of the XG Firewall, and finally the IP address
of the next routing hop. This is the LAN IP address of the XG Firewall.
Once all parameters have been configured, click OK to commit the new route to the routing table.

Associate the Route with the LAN Subnet
Public Cloud
With the new route added to the table, all that’s left to do to replace the default system route for
the subnet by attaching the new route table to it.
Select the Subnets menu in the route table, which is just below the Routes section where we just
were, and click Associate.
Select the virtual network from the list, followed by the subnet we created earlier.
Click OK to apply the route table to the selected subnet and replace the system route.

Configure Routing on the XG Firewall
Public Cloud
The gateway is always the

first IP address of the
subnet’s range
Where the subnet is different from the LAN port subnet you will need to configure a route on the XG
Firewall so it knows how to reach the subnet.
To do this create a new static route.
Enter the network and subnet mask of the new subnet in the ‘Destination IP / Netmask’ field,
followed by the gateway IP address. The gateway is always the first IP address of the subnet’s range.
Complete the route by selecting the LAN interface from the ‘Interface’ drop-down menu.

Open Internet Ports in Azure
Open
Public Cloud
Internet
Ports in
Azure

Open Internet Ports in Azure
Public Cloud
Since all deployments in Azure take place behind a NAT boundary this means you will need to open
any inbound ports you need in the network security group for the XG Firewall’s WAN interface.
For example, for IPsec you would need to allow port UDP 500 for IKE traffic and port UDP 4500 for
NAT-T encapsulated IPsec traffic.
The rules can be managed from the Networking section of the virtual machine in the Azure portal.
Set the source of the rule to the public IP address of the on-premise XG Firewall or Any.
Since we are using NAT-T, make sure to allow all source ports by entering a wildcard in the ’Source
port ranges’ field.
Set the ‘Destination’ to either Any or if you want to select just the IP address of the XG Firewall’s
WAN interface select IP Addresses.
Enter the service ports we need to allow for the VPN traffic, and since we need multiple ports, we
can enter them both in the same field by separating them with a comma.
Set the protocol and action, in our example UDP and Allow.
Network Security Groups work on a strict hierarchy, so make sure to set the priority so that it is not
overwritten by another rule with a lower priority.
Lastly, set a name for the rule, and an optionally a description.

in the notes
XG Firewall Deployment in Azure
NSG management-subnet
Sophos XG Routing
N N
PIP I I sophosxg-
sophosxg-public-
C C private-dmz-
dmz-backend
backend
XG Firewall VM
Azure UDR
Public Cloud
10.10.254.0/24
10.10.1.0/24
mgmt-srv-1
10.10.253.4
Sophos XG
Azure UDR
Routing
application-subnet
VM VM
win-app-srv-1 linux-app-srv-1
10.10.2.4 10.10.2.5
This diagram is an example deployment of XG Firewall on Azure.
Note the two DMZ networks. You can deploy DMZ networks as either private or public. A public
DMZ is the security tier that handles connectivity to the Internet. A private DMZ is the security tier
that handles hybrid connectivity.
Microsoft recommends that these two DMZs are separated.
PIP stands for Private IP.
https://en.wikipedia.org/wiki/Private_IP

Hybrid Deployments
Example Azure VPN Gateway Pricing
Public Cloud
When deploying in hybrid environments that include both on-premise and cloud-based devices
there are two ways to create the VPN:
• Between the on-premise XG Firewall and the Azure deployed XG Firewall
• Between the on-premise XG Firewall and Azure, using the Azure VPN Gateway or Azure Express
Route
Note that there is an additional cost for the Azure VPN gateway and Express Route.

Hybrid Deployments with an XG-to-XG VPN
Company Network Azure
Public Cloud
10.2.11.0/24
10.2.1.0/24
10.1.4.0/24
NIC
PIP
10.2.90.0/24
10.1.5.0/24
This is what a standard hybrid deployment would look like using a site-to-site VPN between an on-
premise XG Firewall and a Azure XG Firewall.
Remember, you do not have to have an interface on the XG Firewall for each subnet as Azure can
manage the routing, as long as you create and apply the user defined routes and static routes.

Hybrid Deployments with a VPN Gateway
Company Network Azure
Public Cloud
10.2.11.0/24
10.2.1.0/24
10.1.4.0/24
NIC
PIP
10.2.90.0/24
VPN Gateway
10.1.5.0/24
Alternatively, you can use an Azure VPN Gateway or Express Route for the connection. In this
example the connection would terminate on the Azure VPN Gateway and can be routed to the
private DMZ as per Microsoft’s recommendations.

Hybrid Deployments with a VPN Gateway
Azure VPN Gateways can either be route-based or policy based
To use IKEv2 you must select route-based
XG Firewall still uses policy-based VPN connection to the Azure route-based VPN Gateway
Public Cloud
This has the limitation of a single security association (SA)
Configure the XG Firewall to Respond only
Configure the XG Firewall WAN interface MSS to 1350 or MTU to 1400 to avoid
fragmentation on Azure
https://docs.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpn-devices
https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-tcpip-performance-tuning
NAT-T is not supported by Azure VPN Gateways
There are two types of Azure VPN Gateway, route-based and policy-based. To use IKEv2, you must
select the routed-based Azure VPN Gateway.
You can use a policy-based VPN to an Azure route-based VPN Gateway, but this has the limitation of
one security association (SA) by default.
Configure the XG Firewall to Respond only. This is to ensure that XG tunnels to Azure are never
interrupted when there is regular maintenance on the Azure Gateway tenants.
Configure the XG Firewall WAN interface MSS to 1350 or the MTU to 1400 to avoid fragmentation on
the Azure side. This is to ensure sure that the TCP packets leaving the XG Firewall towards the Azure
VPN Gateway are at most 1350 bytes after the IPsec layer is peeled away by the Azure gateways.
https://docs.microsoft.com/azure/vpn-gateway/vpn-gateway-about-vpn-devices
https://docs.microsoft.com/azure/virtual-network/virtual-network-tcpip-performance-tuning
Note that NAT-T is not supported by Azure VPN gateways so the XG Firewall must not be behind a
NAT device.

Route-Based VPN to Azure VPN Gateway 1/6
Local Network
Gateway Gateway
Subnet
Public Cloud
Configure the public

IP address of your Add a gateway
on-premise XG subnet to your Azure
Firewall virtual network
Specify the address This is where the

space that is VPN Gateway will be
accessible over the deployed
VPN
Let’s look at how you can configure a route-based VPN between XG Firewall and Azure VPN
Gateway.
Start by creating an Azure Local Network Gateway. Here you configure the public IP address on your
on-premise XG Firewall and specify the address space that is accessible over the VPN.
You need to add a gateway subnet to your Azure virtual network. This is where the VPN Gateway will
be deployed.

Virtual Network
Gateway
Public Cloud
Set the Gateway type

to VPN and the VPN
type to Route-based
Select the virtual

network to associate
the VPN gateway
with
Next create the Virtual Network Gateway. In the configuration specify the gateway type as VPN and
VPN type as Route-based. Here you select the virtual network you want to associate the VPN
gateway with. You can only select virtual networks in the same region and that have a gateway
subnet.
Note that it can take up to 45 minutes to create the VPN Gateway.

Download
Connection
Add Connection
Configuration
Set the connection to
Public Cloud
Site-to-Site (IPsec) Download the

configuration from
Select the Local the connection
Network Gateway
that you created For ‘Device vendor’
earlier select Generic
samples
Specify a preshared
key and select IKEv2 For ‘Device famil’
select Device
parameters
You can now add a connection to the VPN Gateway. Set the connection to site-to-site and select the
Local Network Gateway that you created earlier. Specify a preshared key and select IKEv2.
Once the connection has been created, download the configuration file with the details. Select the
device vendor Generic Samples and the device family Device Parameters.
You will need to use the information from the Tunnel interface (VTI) configuration section to
configure the XG Firewall.

IPsec Site-to-Site
VPN
Set the Connection

type to Tunnel
Public Cloud
interface
Select the Microsoft

Azure policy
Select the listening

interface
Enter the tunnel

destination from the
configuration file
On the XG Firewall, create the VPN connection. Set the connection type to Tunnel interface and
gateway type to Respond only.
Use the Microsoft Azure policy and set the preshared key.
Select the listening interface. This must match the public IP address you set in the Local Network
Gateway on Azure.
You can find the gateway address in the configuration file you downloaded, it is called tunnel
destination.
Save and enable the connection, then establish the connection.

Xfrm Tunnel
Interface
Set the Connection

type to Tunnel
Public Cloud
interface
Select the Microsoft

Azure policy
Select the listening

interface
Enter the tunnel

destination from the
configuration file
Configure the xfrm tunnel interface using the information from the configuration file. Remember to
override the MSS value and set it to 1350.

Static Route
Public Cloud
Gateway and
SD-WAN Policy
Route
The last step is to configure routing and create the necessary firewall rules.
Here are examples of what the routes could look like. The first example is a static route the defines
the destination network and interface only.
In the second example we have created a gateway for the interface, but like the static route, set no
gateway IP. This is coupled with an SD-WAN policy route.
When creating the firewall rules , remember that the connection will be in the VPN zone.

HA on Azure Internet
Azure Load Balancer

Traffic Manager
Cloud Access
Tier
Network Security Groups Network Security Groups
Public Cloud
VNet
subnet
Security Tier XG Firewall XG Firewall
subnet
We will now look at how XG Firewall can be deployed in a high availability configuration on Azure.
Note that only active-active HA is supported on Azure.
To simplify the diagram we have removed the lower two tiers, the Identity tier and the App and Data
tier, and we will focus on the Security and Cloud Access tiers.
Microsoft recommends you build critical components as part of an Availability Set, and you can
deploy multiple XG Firewalls as part of exactly this type of setup, optionally with their own Network
Security Groups.
To direct inbound traffic to multiple firewalls we leverage platform level services that are both fault
tolerant and highly scalable; we use the Azure Load Balancer to direct inbound traffic to all the
members of the Availability Set. This makes sure that persistence is tracked, allowing for graceful
session failover, while also serving as an impartial observer to determine if the XG Firewalls are all
still healthy.
This setup still supports Traffic Manager to load balance multiple independent sites for geographical
redundancy.

Azure Load Balancer

Traffic Manager
Cloud Access
Tier
Public Cloud
VNet
subnet
Azure Load Balancer

subnet
Now we have a redundant path for inbound traffic to securely reach its destination, what about
outbound traffic?
The obvious solution is to use another Azure Load Balancer. By directing HTTP/HTTPS proxy traffic at
the load balancer, it can leverage all nodes in the cluster for outbound web filtering.
Traffic comes in, just like the inbound scenario, and is then distributed to any healthy node in the
Availability Set allowing traffic to be balanced to multiple nodes while health and persistency is
tracked by the Azure Load Balancer as an impartial observer.

Azure Load Balancer

Traffic Manager
Cloud Access
Tier
Public Cloud
VNet
subnet
Azure Load Balancer

subnet
The only limitation of this setup is that routed (non-proxy) traffic can only flow to a single node at
any given time. So for traffic to and from your VPN or ExpressRoute for example, you would need to
configure scripting (preferably in Azure code, but any witness with the ability to run Azure CLI would
work) to change both the App tier and Remote site route table entries if one of the nodes in the
Availability Set fails.

HA on Azure
Public Cloud
• Two XG Firewalls in an availability set with two NICs each (one frontend and one backend)
• A public load balancer with a public IP resource attached
• The load balancer checks the health of the XG appliances using TCP port 4444
• TCP port 4444 on the public IP of the load balancer is NATed to TCP port 4444 of the first XG
Firewall
• TCP port 4445 on the public IP of the load balancer is NATed to TCP port 4444 of the second XG
Firewall appliance
On the Sophos IaaS Github page is an ARM template for high availability deployment. This template
can be downloaded and customized to integrate the deployment into an existing environment, or
the default template can be deployed directly from the Sophos IaaS Github page.
The template deploys the following:

• Two XG Firewalls in an availability set with two NICs each (one frontend and one backend)
• A public load balancer with a public IP resource attached
• The load balancer checks the health of the XG appliances using TCP port 4444
• TCP port 4444 on the public IP of the load balancer is NATed to TCP port 4444 of the first
XG Firewall
• TCP port 4445 on the public IP of the load balancer is NATed to TCP port 4444 of the
second XG Firewall appliance

Course Review
Now that you have completed this course, you should be able to:
Choose the most appropriate type for web protection in different deployment scenarios
Enable web filtering using the DPI engine or legacy web proxy
Configure TLS inspection using the DPI engine or legacy web proxy
Deploy an XG Firewall on Azure
Configure XG Firewall for hybrid deployments and deploy a high availability pair of XG Firewalls on
Azure
Continue
On completion of this course, you should now be able to perform the actions shown here. Please
take a moment to review these.
If you feel confident that you have met these objectives, click Continue.

TRAINING FEEDBACK
Feedback is always welcome

Please email globaltraining@sophos.com
Feedback on our courses is always welcome.
Please email us at globaltraining@sophos.com with your comments.

Next Steps
Now that you have completed this course, you should:
Complete the assessment You have 1 hour to complete You have 4 attempts to
in the training portal the assessment pass the assessment
Now that you have completed this course, you should complete the assessment in the training
portal.
You will have 1 hour to complete the assessment from when you launch it, and you have 4 attempts
to pass the assessment.


AU80 v17.5 To v18.0 XG Firewall Training Update

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AU80 v17.5 To v18.0 XG Firewall Training Update

Uploaded by

Copyright:

Available Formats

Sophos Delta Training

Version 17.5 to 18.0

Sophos Certified Delta

Sophos XG Firewall v18.0 Architect Delta - 1

Course Duration This course will take around 45 minutes to complete

Certified in XG Firewall Architect and any subsequent delta

Sophos XG Firewall v18.0 Architect Delta - 2

A glossary of technical terms used throughout the course

Sophos XG Firewall v18.0 Architect Delta - 3

Sophos XG Firewall v18.0 Architect Delta - 4

Feedback is always welcome

Feedback on our courses is always welcome.

Please email us at globaltraining@sophos.com with your comments.

Sophos XG Firewall v18.0 Architect Delta - 5

Sophos XG Firewall v18.0 Architect Delta - 6

Sophos XG Firewall v18.0 Architect Delta - 8

Gateway or mixed mode deployments

LAN Zone WAN Zone

Filter web traffic

Sophos XG Firewall v18.0 Architect Delta - 9

Bridge mode deployments

Sophos XG Firewall v18.0 Architect Delta - 10

Explicit proxy deployments

Sophos XG Firewall v18.0 Architect Delta - 11

Typically deployed at the gateway

Sophos XG Firewall v18.0 Architect Delta - 12

Ports Any 80 & 443 only

FastPath Support Yes No

SafeSearch Enforcement No * Yes

YouTube Restrictions No Yes

Explicit Proxy No Yes

Content caching No Yes

Parent Proxy No Yes

Sophos XG Firewall v18.0 Architect Delta - 13

Decrypt Web Content

sophos.com on port 443 Web Proxy

sophos.com on port 8080

Sophos XG Firewall v18.0 Architect Delta - 14

Decrypt Web Content

sophos.com on port 443 Web Proxy

sophos.com on port 8080

The legacy web proxy is also used in explicit proxy configurations.

Sophos XG Firewall v18.0 Architect Delta - 15

Content Filter Action Status

Sophos XG Firewall v18.0 Architect Delta - 16

The available options are:

Sophos XG Firewall v18.0 Architect Delta - 17

Sophos XG Firewall v18.0 Architect Delta - 18

Sophos XG Firewall v18.0 Architect Delta - 19

are not decrypting SSL

• 80% of traffic is encrypted

Sophos XG Firewall v18.0 Architect Delta - 20

Sophos XG Firewall v18.0 Architect Delta - 21

These settings cover:

Sophos XG Firewall v18.0 Architect Delta - 22

There are three default profiles out-of-the-box that cover:

You can also create custom profiles. In them you can:

Sophos XG Firewall v18.0 Architect Delta - 23

There is a more limited set of options, but you can:

Sophos XG Firewall v18.0 Architect Delta - 24

Sophos XG Firewall v18.0 Architect Delta - 25

Sophos XG Firewall v18.0 Architect Delta - 26

Sophos XG Firewall v18.0 Architect Delta - 27