Why do we have to Route and NAT of the VPN traffic although these traffic naturally have to be encapsulated in IPSec Payload ???

Don't get the idea of this KB.

Mikel,

Its quite simple.

Network A is on your Local Site. 

Network B on your Remote Site.

XG build a SA between Network A and Network B in IPsec. So the route Exist between both.

But - XG itself does not know the route.

So you have to manually add this route to tell XG "system originated Traffic" like Authentication, Email etc. 

Hi Lucar,

It's actually a bit more complex than that and the reason this KB exists is because the XG does not actually apply IPSEC routing to it's own initiated traffic.

The reason for this is because the IPSEC routing is post the processing phase and before passover to the Routing phase (in my own terms). So therefore traffic that is pass through the XG will be compared to requirements to be passed through the IPSEC tunnel but because the XG traffic is sent directly from its interfaces it really only compares it traffic against the standard routing table of which the IPSEC routing is not entered within it (do a route print in the CLI and it does not exist there).

So therefore we have to tell the XG system itself to use the IPSEC tunnel for traffic targeting a specifc IP/range and then because the IPSEC tunnels are bound to the "WAN" interface, to prevent it using the WAN IP we have to tell it to NAT itself for communications against those match conditions for those targets. And to make sure it sits appropriately within the SA.

It is odd and makes not too much sense but there is a reason behind it but I cannot remember off the top of my head. It was a design decision left over from Cyberoam. I believe this will change in v18 because to allow Route Based VPNs and SD-WAN type functionality I would expect the IPSEC routes to have to exist in the main kernel routing table.

Emile

Thanks bro,

I got the idea now.

According to the 

Sophos XG Firewall: Clientless Single Sign-On in a Single Active Directory Domain Controller environment

https://community.sophos.com/kb/en-us/123156

How STAS works?

1. The user logs in to the Active Directory (AD) Domain Controller from any workstation in the LAN. The Domain Controller authenticates the user's credentials
2. AD gets the user logon session information and creates a security audit log. Upon successful user authentication, AD creates an event with an ID of 672 (Windows 2003) or 4768 (Windows 2008 and above).
3. The Agent, while monitoring the AD server, gets the user logon session information from the above event IDs.    
4. The Agent passes on the username and IP address to the Collector over the default TCP port (5566) at the same time.
5. The Collector responds by sending successful authentication updates to the XG Firewall on UDP port 6060.
6. If the XG see traffic from an IP it has no information on it can query the collector on port 6677.
7. A user initiates an internet request.
8. The XG Firewall matches the user information with its local user map and applies security policies accordingly. 

In this case, when the BO Firewall doesn't have user information about the LAN Branch Office's PC, it will query the AD Server in HO --> This traffic isn't included in the original configured ACL of the IPSec connection (because it originates from the BO firewall itself) ==> So we need to configure ROUTE and NAT for this firewall self-originated query traffic :)

Brgs

Hi Emile,

do i get the idea right in this case ???

According to the 

Sophos XG Firewall: Clientless Single Sign-On in a Single Active Directory Domain Controller environment

https://community.sophos.com/kb/en-us/123156

How STAS works?

1. The user logs in to the Active Directory (AD) Domain Controller from any workstation in the LAN. The Domain Controller authenticates the user's credentials
2. AD gets the user logon session information and creates a security audit log. Upon successful user authentication, AD creates an event with an ID of 672 (Windows 2003) or 4768 (Windows 2008 and above).
3. The Agent, while monitoring the AD server, gets the user logon session information from the above event IDs.    
4. The Agent passes on the username and IP address to the Collector over the default TCP port (5566) at the same time.
5. The Collector responds by sending successful authentication updates to the XG Firewall on UDP port 6060.
6. If the XG see traffic from an IP it has no information on it can query the collector on port 6677.
7. A user initiates an internet request.
8. The XG Firewall matches the user information with its local user map and applies security policies accordingly. 

In this case, when the BO Firewall doesn't have user information about the LAN Branch Office's PC, it will query the AD Server in HO --> This traffic isn't included in the original configured ACL of the IPSec connection (because it originates from the BO firewall itself) ==> So we need to configure ROUTE and NAT for this firewall self-originated query traffic :)

Brs

"...So we need to configure ROUTE and NAT for this firewall self-originated query traffic :)"

That's exactly it, because the communications between the XG and STAS are bi-directional, XG > STAS for querying and STAS > XG for live user sync.

Hope that makes sense now!

Emile

Thanks bro,

Your explanation is great and very clear !

Mikel

Brs,

Happy to help!

Emile

Happy to help!

Emile