Policy Route

Hello Thierry MICHELS ,

Thank you for reaching out to the community, Please refer the following useful docs below:

1.) Sophos Firewall v19: How to Choose The Gateway For A Firewall Rule - Sophos Firewall v19: How to Choose The Gateway For A Firewall Rule

2.) SD-WAN policy routing - https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Routing/SDWANPolicyRouting/index.html

3.) Add an SD-WAN policy route - https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Routing/SDWANPolicyRouting/RoutingSDWANPolicyRouteAdd/index.html

With the help of the below command, you may verify the system-generated traffic SNAT details.

If no output which means no SNAT configured for system-generated traffic.

console> sh advanced-firewall

Below output will help on SNAT for system-generated traffic :

NAT policy for system originated traffic
---------------------
Destination Network Destination Netmask Interface SNAT IP

console>

Sophos XG Firewall: How to NAT Sophos Firewall generated traffic

https://support.sophos.com/support/s/article/KB-000035607?language=en_US

For delete, the command will be the same and in place of add, you may use del in the above KBA if you want to delete any existing system-generated NAT Rule.

Thank you for your answer

I tried to add under Remote Subnet the new VLANs and corrected the Firewall rule, but it doesn't work.

The LAN_arosa connect green and the VLAN_Arosa stay red.

Thank you for the update, is VLAN_Arosa is also part of the local subnet in the remote site, can you confirm ? And also ensure the subnet is not conflicting with the LAN_Crans. 

Yes VLAN_Arosa is a VLAN on the same LAN Port

VLAN_Arosa 172.16.20.0/23

LAN_Arosa 172.16.60.0/23

Yes VLAN_Arosa is a VLAN on the same LAN Port

VLAN_Arosa 172.16.20.0/23

LAN_Arosa 172.16.60.0/23

No LAN_Crans is on 192....

Can you enable the strongswan service in debug with the following command:
On the CLI, select option 5. Device Management, then option 3. Advanced Shell. 

#service strongswan:debug -ds  nosync

And then collect the debug logs with the following command, [re-establish the tunnel by toggling off and on]

#tail -f /log/strongswan.log 

Thank you for your help

XG115_XN03_SFOS 19.0.1 MR-1-Build365# debug -ds nosync                         
/bin/sh: debug: not found                                                      
XG115_XN03_SFOS 19.0.1 MR-1-Build365# tail -f /log/strongswan.log              
2023-01-13 08:34:39Z 14[CFG]   loaded IKE secret for 195.162.165.58 %any       
2023-01-13 08:34:39Z 08[CFG] rereading ca certificates from '/_conf/ipsec/ipsec.
d/cacerts'                                                                     
2023-01-13 08:34:44Z 09[DMN] [GARNER-LOGGING] (child_alert) ALERT: Received IKE
message with invalid SPI (E1231F72) from the remote gateway.                   
2023-01-13 08:34:44Z 05[DMN] [GARNER-LOGGING] (child_alert) ALERT: Received IKE
message with invalid SPI (E1231F72) from the remote gateway.                   
2023-01-13 08:34:45Z 06[DMN] [GARNER-LOGGING] (child_alert) ALERT: Received IKE
message with invalid SPI (E1231F72) from the remote gateway.                   
2023-01-13 08:34:47Z 30[DMN] [GARNER-LOGGING] (child_alert) ALERT: Received IKE
message with invalid SPI (E1231F72) from the remote gateway.                   
2023-01-13 08:34:51Z 23[DMN] [GARNER-LOGGING] (child_alert) ALERT: Received IKE
message with invalid SPI (E1231F72) from the remote gateway.                   
2023-01-13 08:34:59Z 14[DMN] [GARNER-LOGGING] (child_alert) ALERT: Received IKE
message with invalid SPI (E1231F72) from the remote gateway.                   
2023-01-13 08:35:15Z 12[DMN] [GARNER-LOGGING] (child_alert) ALERT: Received IKE
message with invalid SPI (E1231F72) from the remote gateway.                   
2023-01-13 08:35:45Z 28[DMN] [GARNER-LOGGING] (child_alert) ALERT: Received IKE
message with invalid SPI (E1231F72) from the remote gateway.                   

You executed the wrong command for debug Thierry MICHELS use the complete command after the #

anyways, in the normal logs we can see, we are receiving invalid SPI [Security Parameter Index] please get it checked with the remote site's logs once...

Ok sorry I am not familiar with the debug.

But anyway like you say : receiving invalid SPI

When I remove the second one (VLAN_Arosa) its works fine without errors

Yup, so please check the logs on the remote site to narrow down the situation !

Just one question:

Should the method I chose work?

If so, I think the problem is on the other side. And they need to check their configuration

Correct, please inform the team check on the remote site !

Better asked question

Could I have 2 different Subnet in the remote subnet section

Of course, but whatever changes you make locally need to be reflected on the remote site !