Sophos XG firewall version 18 introduces various policy based routing
enhancements as part of SD when functionality in this video we will look
at those enhancements discuss the scenarios and demonstrate how
administrators can cater to some customer requirements with the help of
new SD when policy routes in version 17 while having multiple LAN links we were
able to take the gateway based routing decisions for the traffic such as load
balancing or route via specific gateway link from the firewall rules itself
however from version 18 onwards the gateway based routing has been decoupled
from the firewall rules and managed separately from the Sdn policy routing
section with version 18 the user based as well as application based routing has
been introduced in the traffic matching criteria section of the SD when policy
routing to offer more granularity and flexibility while making routing
decisions the prerequisites for this feature are the Sophos XG firewall must
be running version 18 or above and more than one gateway must be configured on
XG firewall to make use of policy based routing effectively this is the network
diagram we are considering as an example to configure Sdn policy routing as we
can see there are two active ISP links available on the branch office XG device
and the land users are in the 172 dot 16160 / 24 subnet range as per the
requirements of the customer the traffic of all the streaming media applications
originated from any land machine must be routed via the ISP one link only and all
the 80 and 443 traffic originated from the land users must be routed via ISP to
to the web proxy server located in the head office so let's take a look at
the configuration steps needed on XG version 18 to achieve this requirement
to route all the streaming media applications from the ISP one link for
the land users please make sure that a firewall rule is already created to
allow traffic from the land zone going to the land zone which is the internet
then we navigate to configure click on routing and then st wind policy routing
and click on the Add button enter an appropriate name and under the source
network section we create a new IP host object for the LAN subnet range 172 dot
16 dot 16.0 with a subnet range of slash 24 under the application object section
we create a new application object by giving an appropriate name then select
the category as streaming media so that all the streaming applications are
automatically selected and then click on the Save button optionally if only
certain authenticated users or groups are considered for this requirement then
we can also select them from the users or groups section as matching criteria
then select the is p1 gateway as the primary gateway in some cases you may
also select other available gateways or the when link load balancing option if
traffic needs to fail over the other when links in case the primary link
fails in this example we are keeping it as none enable the override gateway
monitoring decision option so that the streaming applications are routed via
ISP one link only irrespective of the Gateway status then save the policy
route configuration by clicking on the Save button now to route the 80 and 443
traffic via ISP to we need to create another policy route by clicking on the
Add button enter an appropriate name under the source network section we
select the 170 to 1616 0/24 IP host object and then in
the services section we select HTTP and HTTPS select the ISP to Gateway as the
primary gateway and finally click on the Save button
so with these Sdn policy routes in place all the streaming applications will
always be routed to the ISP one link via the first policy route and the 80 and
443 traffic will be routed to the ISP to link via the second policy route now
here is another scenario wherein we can use the SDU and policy routes
effectively to route the traffic between head office and branch office networks
and XG 135 is deployed in the branch office and has land users in the 172 dot
16 16 0 / 24 subnet range the head office land network is one ninety two
dot one sixty eight dot 10.0 / twenty four and is reachable via an IPSec
policy based VPN tunnel as well as an MPLS link as per the customers
requirements the VPN tunnel must be used as the primary default link for the
traffic flow between the head office and branch office and the MPLS link is to be
used as a backup route once the VPN tunnel disconnects the traffic must fail
over to the MPLS link additionally when the VPN tunnel gets re-established
traffic must fail back from the MPLS to the VPN tunnel so let us see the
configuration steps needed on the XG firewall to achieve this requirement
before we start configuring the policy routes make sure that IPSec site-to-site
VPN is configured and connected between the branch office XG 135 and the head
office router device and the appropriate land to VPN and VPN tool and firewall
rules are configured as well the firewall rules also need to be
configured for land 2 MPLS and MPLS to land traffic so that the XG device can
how the traffic to pass through when the traffic fails over from the VPN tunnel
to the MPLS link first we need to create a gateway MPLS GW on MPLS port seven of
the XG device as the MPLS connectivity is available via that interface select
the health check option as ping for the remote side IP 2.2 2.1 so that whenever
the XG device is unable to reach this IP via port 7 the MPLS GW gateway should be
considered down now we navigate to configure click on routing and then s
queuing policy routing then click on add enter an appropriate name under the
source network section we select the IP host object created for 172 dot 16 16.0
network for the destination network we select the IP host object created for
the one ninety two dot one sixty eight dot 10.0 network select the MPLS GW as
the primary gateway and click on the Save button now to set the VPN tunnel as
the primary link for the traffic flow we need to select option 4 from the SSH
console access of the device and execute this command once we execute this
command and reconnect the IPSec VPN tunnel the traffic would be routed via
the VPN tunnel by default and once the tunnel is down then it will failover the
traffic to the MPLS link and use the SD wind policy routes for routing decisions
also to make sure that the reply traffic for the head office initiated traffic
flows over the Sdn policy routing we need to make sure that the option for
reply traffic is enabled via this command so in this way you can achieve
the VPN to MPLS failover as well as failback with the help of Sdn
policy routing alternatively the same scenario can
be achieved using a single St wind policy route even without changing the
route precedence by configuring the newly introduced route based IPSec VPN a
gateway can be configured on this VPN tunnel virtual interface and then it can
be used to route the traffic between the IPSec VPN connection and the MPLS
selectively even when both the links are active some additional SD wind policy
routing enhancements introduced in version 18 are once the policy route is
created we can check the status of the Gateway whether it is green red or amber
red means the active and backup gateways are down and the override gateway
monitoring flag is disabled green means either the primary or backup
gateway is up an Amber means the active and backup gateways are down and the
override gateway monitoring flag is enabled we can also disable or enable
the route with the help of a toggle switch the order of the SD when Policy
routes can also be modified in a drag-and-drop manner we can also clone
the existing policy routes and use them as a kind of template to configure
similar types of policy routes the applications discovered by the
synchronized application control functionality can also be selected in
the application object and used for Sdn application based policy routing as we
have decoupled the route through gateway option from the firewall rules in XG
version 18 we have changed the default route precedents to adhere to common
deployment use cases a fresh install of a version 18 device will have the
default route precedence as static Sdn policy route VPN the current route
precedents and the policy route association with the reply traffic and
system generated traffic will be shown on the Sdn policy route screen its
now let us discuss the version 17 - version 18 migration behavior to ensure
a smooth migration from version 17 to version 18 the firewall rules have route
through gateway option selected as any specific gateway would be migrated and
shown under the migrated ipv4 Sdn policy route section and they would be linked
back to their associated firewall rule IDs the policy based routing for the
reply packets also would not be applicable for version 17 - version 18
migration and the option is kept disabled by default so if required the
user can enable this option from the SSH console with the help of the following
command some of the caveats associated with this feature are on the deletion of
the primary gateway The Associated policy routes will be deleted as well
and the traffic will be load balanced between the active lan links this is the
default behavior for routing the traffic when no Sdn policy route exists in most
cases of application based routing the first connection from an application
will be routed through the default when link load balance method because the
application cache is initially not aware of the destination IP and port
information for the very first connection once it is learned all the
subsequent connections will adhere to their Associated application based
routes until the TTL is expired application based routes require an
active web protection license one of the following conditions must be met to make
use of application based routing application classification must be
turned on an application filter policy should be applied to the Associated
firewall rule or the application must be part of the offload signatures and
flowing through snort the IPS engine ideally the policy routes would be
removed from the kernel routing table one
The Associated Gateway goes down however if the override gateway monitoring
decision flag is enabled then the policy routes remain persistent in the routing
table for new version 18 installations the policy based routing for the reply
packets would also be applicable and the option is enabled by default
with the deep packet inspection scanning method the application based routing is
supported for all the applications however with the legacy web proxy the
application based routing is supported for pattern apps and sync cick apps and
not supported for the micro apps finally let us see some of the troubleshooting
steps related to Sdn policy routing considering this scenario wherein a user
is trying to access these Sophos test.com website from a computer having
an IP address of 172 dot 16 dot 1634 and we have created an st wind policy route
to route the traffic destined to Sophos test comm through the isp to link so now
we will look at the steps regarding how to identify the Gateway and Sdn
policy-based routing associated with this traffic the user will access the
Sophos test.com website and then perform the nslookup to identify the IP address
of the website once the IP address is known we navigate to the Diagnostics
connection list then click on the display filter button enter the IP
address of the website in the destination IP text box and click on
apply to save the filter it will show the gateway ID with a prefix 0x 40 which
means that the routing was done via SD wind policy routes and hovering the
cursor on the gateway ID shows the name of the Gateway which is ISP to in our
case for detailed troubleshooting via CLI
we will open an SSH console session on the device and navigate to option 5 and
then option 3 to get shell access then we will use the contract command to see
the connection details of the traffic that is initiated by the land user for
the Sophos test.com website as we can see it shows the mark ID starting with 0
x 40 if it shows the mark ID starting with 0 X 80 it means that the traffic is
routed via the traditional LAN link load balancing method to identify the Gateway
associated with the mark ID we type in the command IP rule LS as we can see 0 x
4 0 0 2 is gateway 2 then we use the IP route command for Gateway to to see the
associated interface of this gateway and as we can see it shows that port 6 has
the ISP to link terminated on it along with its Gateway IP now to identify
which Sdn policy route is used for the traffic we can see the PBR ID underscore
dir 0 value from the contract which means that for the associated request
traffic it has matched with the policy route ID 4 so we use the IP tables
command to see the list of Sdn policy routes configured on the XG device as we
can see the policy route having the ID value of 4 is on the 3rd position in the
list in the web UI we can confirm the policy route configured in the third
position on the list and accordingly conclude that the traffic is getting
routed via the correct policy route configured for the required traffic in
this way SD win policy routes in version 18 can be used for standard as well as
advanced customer requirements along with great flexibility WeHo
you like this video and thank you for watching