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,

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

Hello Emile,

I agree with you, the whole implementation of VPN networks in XG is one huge problem. Have to implement a NAT into site-to-site IPsec tunnels is sooner or later a path to hell. Sooner or later you will find that you have one big problem that is bigger and bigger and from which there is no other way than to build from the beginning and without NAT.

And at this stage I think Sophos with XG is. Because they found that the kernel built on BusyBox is one big problem and they are overwrite the XG kernel for v18 into Ubuntu. Which I think is also not a good choice, but what stable and reliable Linux kernel is available for free, isn't?

Let's hope will be better in this fall.

Regards

alda

Hi Alda,

Currently the XG is built on Ubuntu Linux 3.14.22, BusyBox is just a Command Line Interface layer to prevent direct interaction with Root Kernel. But yes, there will be a full Ubuntu Server Kernel upgrade this year (was started pretty much at v15 to be done).

The VPN system is functional and in some cases is very efficient, by its VPN interface stack being complete separate, you do not need to worry about decrypting and de-encapsulating packets if you want to do traffic analysis (if it hits the ipsec0 interface, you know it has been sent!).

However, I do think they need to re-integrate the IPSEC system back into the main stack but I also see the benefits of it being separate. The only thing that I wish that would happen to square the circle is that this NAT-ing and System Traffic routing happened automatically as part of the IPSEC tunnel creation/destruction. This is because I too have been caught out by accidentally leaving a sys-traffic-nat or IPSEC_Route in and forgetting to change it when a new tunnel is activated.

At least if it were automatic, the ambiguity of this behaviour would never come up in casual conversation or issue diagnosis.

Emile