With version 18, we have added the route-based VPN method into the framework of IPSec VPN
functionality. Route-based VPN creates a virtual tunnel interface
(VTI) that logically represents the VPN tunnel, and any traffic that is routed towards this
interface is encrypted and sent across the tunnel.
Static, dynamic, and the new SD-WAN Policy-based routing can be used to route the traffic via
the VTI.
The pre-requisite is that the Sophos XG must be running SFOS version 18 or above.
The following is the diagram we are using as an example to configure a Route Based IPsec
VPN
XG devices are deployed as gateways in the Head Office and Branch Office locations.
In the Head Office network, Port2 is the internet-facing WAN interface configured with the IP address
192.168.0.77. Port1 is the LAN interface configured with
the IP address 172.16.1.13, and its LAN network resources are in the 172.16.1.0/24 subnet
range.
In the Branch Office network, Port2 is the internet-facing WAN interface configured with
the IP address 192.168.0.70. Port1 is the LAN interface configured with
the IP address 192.168.1.75, and its LAN network resources are in the 192.168.1.0/24 subnet
range.
As per the customer’s requirement, the Branch Office LAN network should be able to connect
to the Head Office LAN network resources via the IPsec VPN tunnel, and the traffic flow
should be bi-directional.
So, let us see the steps to configure this scenario on XG version 18:
The Brach office XG acts as the initiator of the VPN tunnel and the Head Office XG device
as the responder.
So first, we go through the configuration steps to be done on the Head Office XG.
Navigate to CONFIGURE>VPN>IPsec Connections and click on the Add button.
Enter an appropriate name for the tunnel, Enable the Activate on Save checkbox so that
the tunnel gets activated automatically as soon the configuration is saved.
Select the Connection Type as Tunnel Interface and Gateway Type as Respond only.
Then select the required VPN policy. In this example, we are using the in-built IKEv2 policy.
Select the Authentication Type as Preshared Key and enter the Preshared Key.
Now under the Local Gateway section, select the listening interface as the WAN Port2.
Under Remote Gateway, enter the WAN IP address of the Branch Office XG device.
The Local and Remote subnet fields are greyed out because it is a route-based VPN. Click
on the Save button, and then we can see the VPN connection configured and activated successfully.
Now navigate to CONFIGURE>Network>Interfaces, and we can see xfrm interface created on the
WAN interface of the XG device. This is the virtual tunnel interface created for the IPSec
VPN connection, and once we click on it, we can assign an IP address to it.
The next step is to create firewall rules so that the branch office LAN network can
allow the head office LAN network traffic and vice versa.
(Firewall rule config) So first, we navigate to PROTECT>Rules and
policies>Firewall rules and then click on the Add firewall rule button.
Enter an appropriate name, select the rule position and appropriate group, logging option
enabled, and then select source zone as VPN. For the Source network, we can create a new
IP host network object having the IP address of 192.168.1.0 with a subnet mask of /24.
Select the Destination zone as LAN, and for the Destination networks, we create another
IP host network object having the IP address of 172.16.1.0 with a subnet mask of /24. Keep
the services as Any and then click on the Save button.
Similarly, we create a rule for outgoing traffic by clicking on the Add firewall rule button.
Enter an appropriate name, select the rule position and appropriate group, logging option
enabled, and then select source zone as LAN. For the Source network, we select the IP host
object 172.16.1.0. Select the Destination zone as VPN, and for
the Destination networks, we select the IP host object 192.168.1.0. Keep the services
as Any and then click on the Save button.
We can route the traffic via xfrm tunnel interface using either static routing, dynamic routing,
or SD-WAN Policy routing methods. In this video, we will cover the static routing
and SD-WAN policy routing method for the VPN tunnel traffic.
So, to route the traffic via static route, we navigate to Routing>Static routing and
click on the Add button. Enter the destination IP as 192.168.1.0 with
subnet mask as /24, select the interface as xfrm tunnel interface, and click on the Save
button.
Now with version 18, instead of static routes, we can also use the new SD-WAN Policy routing
method to route the traffic via xfrm tunnel interface with more granular options, and
this is best used in case of VPN-to-MPLS failover/failback scenario.
So, to route the traffic via policy route, we navigate to Routing>SD-Wan policy routing
and click on the Add button. Enter an appropriate name, select the incoming
interface as the LAN port, select the Source network, as 172.16.1.0 IP host object,
the Destination network, as 192.168.1.0 IP host object,
Then in the primary gateway option, we can create a new gateway on the xfrm tunnel interface
with the health check monitoring option as ping for the remote xfrm IP address 4.4.4.4
and then click on save. Navigate to Administration>Device Acces and
enable the flag associated with PING on the VPN zone to make sure that the xfrm tunnel
interface IP is reachable via ping method. Additionally, if you have MPLS link connectivity
to the branch office, you can create a gateway on the MPLS port and select it as the backup
gateway, so that the traffic failovers from VPN to MPLS link whenever the VPN tunnel goes
down and failback to the VPN connection once the tunnel is re-established.
In this example, we will keep the backup gateway as None and save
the policy.
Now from the command line console, make sure that the sd-wan policy routing is enabled
for the reply traffic by executing this command. If it is turned off, then you can enable it
by executing this command. So, this completes the configuration on the
Head office XG device.
On the branch office XG device, we create a similar route-based VPN tunnel that has
the same IKEv2 VPN policy, and the pre-shared key,
the listening interface as the WAN interface Port2.
And the Remote Gateway address as the WAN IP of Head Office XG device.
Once the VPN tunnel is connected, we navigate to CONFIGURE>Network>Interfaces and assign
the IP address to the newly created xfrm tunnel interface.
To allow the traffic, we will navigate to PROTECT>Rules and policies>Firewall rules
and create 2 firewall rules, one for the outbound and one for the inbound traffic flow with
the branch office and head office LAN network subnets.
Now, to route the traffic via static route, we can navigate to Routing>Static routing
and create a static route having the destination IP as
The 172.16.1.0 network with the xfrm selected for the outbound interface.
As discussed earlier, if the routing needs to be done via the new SD-WAN policy routing,
then we can delete the static routes and then navigate to Routing>SD-Wan policy routing
and create a policy having the incoming interface as the LAN port,
Source network, as 192.168.1.0 IP network the Destination network, as 172.16.1.0 network.
Then in the primary gateway section, we create a new gateway on the xfrm tunnel interface
with health check monitoring option as ping for the remote xfrm IP 3.3.3.3
And select it as the primary gateway, keep the backup gateway as None and save
the policy.
From the command line console, we will ensure that the sd-wan policy routing is enabled
for the reply traffic. And this completes the configuration on the
Branch office XG device.
Some of the caveats and additional information associated with Route based VPN in version
18 are:
If the VPN traffic hits the default masquerade NAT policy, then the traffic gets dropped.
So, to fix it, you can add an explicit SNAT policy for the associated VPN traffic.
Even though it is not recommended generally, but if you configure IPSec connection between
policy-based VPN and route-based VPN and face some issues, then make sure that the route-based
VPN is kept as responder, to achieve positive results.
Deleting the route-based VPN connections deletes the associated tunnel (xfrm) interface
and its dependent configurations. Unbinding the WAN interface will also delete
the corresponding XFRM tunnel interface and the IPSec VPN connection.
Here are some workflow differences between Policy-based VPN and Route based VPN:
Auto creation of firewall rules cannot be done for the route-based type of VPN, as the
networks are added dynamically. In the scenarios having the same internal
LAN subnet range at both the head office and branch office side, the VPN NAT-overlap needs
to be achieved using the Global NAT rules.
Now lets see some features not supported as of today, but will be addressed in the future
release: GRE tunnel cannot be created on the XFRM interface.
Unable to add the Static Multicast route on the XFRM interface.
DHCP relay over XFRM.
Finally, let us see some of the troubleshooting steps to identify the traffic flow for the
route-based VPN connection:
Considering the same network diagram as the example and a computer having the IP address
192.168.1.71 located in the Branch office is trying to ping the web server 172.16.1.14
located in the Head office. So to check the traffic flow from the Branch
office XG device, we navigate to Diagnostics>Packet capture and click on the Configure button.
Enter the BPF string as host 172.16.1.14 and proto ICMP and click on the Save button.
Enable the toggle switch, and we can see the ICMP traffic coming from LAN interface Port1
and going out via xfrm interface. Similarly, if we open the Log viewer, select
the Firewall module and search for the IP 172.16.1.14, we can see the ICMP traffic passing
through the xfrm interface of the device with the associated firewall rule ID.
Once we click on the rule ID, it will automatically open the firewall rule in the main webUI page,
and accordingly, the administrator can do further investigation, if required.
In this way, route-based IPSec VPN in Sophos XG version 18 can be used for connectivity
in Head-office, Branch-office scenarios, and can also be used to establish the VPN connection
with the other vendors supporting route-based VPN method.
We hope you liked this video and thank you for watching.