Set source IP for site to site IPSec VPN using 'Tunnel Interface' connection type linking multiple subnets

Hi  JasP , 
                          For Routebased VPN ( 'Tunnel Interface' ) with ANY-ANY traffic selectors (that use routing), you can use the NAT MASQ  rule .
https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/RulesAndPolicies/NATRules/index.html#firewall-rules-and-nat-rules

for route-based VPNs, the firewall translates the original source to the XFRM IP address for the translated source set to MASQ.

Regards,
Vamshi

vamshi d said:

for route-based VPNs, the firewall translates the original source to the XFRM IP address for the translated source set to MASQ

This is the problem, the XFRM IP doesn't stay the same each time the tunnel is torn down and rebuilt (e.g. when the XG is rebooted).

In my example above, the XFRM IP can be 192.168.1.1, 192.168.2.1 or 192.168.3.1 and there appears to be no consistency which it chooses. I suspect this is a 'bug/missing feature' issue but before I rebuild all our VPNs using a site-site connection type I thought I would ask the question to see if there was any way to stop my XFRM IP from 'wandering' and consistently pick the same IP.

This problem also breaks our SNMP monitoring of the tunnel because when it changes the IP, the details for the xfrm interface change and it is no longer recognised and has to be set up again.

Hi JasP , The XFRM IP address is the one binded to the XFRM interface ( under Network->Interfaces)  and so it will always be unique. 


https://docs.sophos.com/nsg/sophos-firewall/18.5/Help/en-us/webhelp/onlinehelp/AdministratorHelp/VPN/SiteToSiteVPN/VPNCreateRouteBasedVPN/index.html#introduction

If I understand your topology right, I believe 192.168.1.1, 192.168.2.1 or 192.168.3.1 are the connected LAN interface IPs. 

Regards,

Vamshi

Thanks for your suggestions with this Vamshi. I have come to the conclusion that I am asking the wrong question!

I reviewed the article you linked to and it appears to add steps that are not necessary. There is no requirement to setup an XFRM IP or routes for the tunnel to work. Indeed if you go into the XFRM interface, my IPs are blank and it says "The XFRM interface is configured for specific local and remote subnets. You don't need to assign an IP address or routes to the interface." This is correct as none of my site to site VPNs have IPs specified for the XFRM interface and I have never had to configure routes.v

Out of curiosity I manually set an IP at one end but not a corresponding IP at the other and the tunnel still connected, so it appears to ignore the XFRM IP setting for a 'Tunnel Interface' site to site VPN.

Presumably there is some mechanism to agree suitable IPs at each end that is transparent to the user. I thought it was using one of the LAN IPs to terminate the tunnel but that is clearly rubbish!

So, my original problem has nothing to do with the tunnel configuration. My problem is that I can't specify the source IP for syslog traffic and the XG picks one of the LAN IPs when it is rebooted, seemingly randomly, so it keeps changing.

As this is unrelated to the question I posted, I will create a new post.

Hi JasP , Thanks for the topology details. 

Generally in SFOS IPsec , The source address is based on the 1st child SA ( local subnet) which gets established after the Tunnel is UP. So hence the behaviour XG picks one of the LAN IPs that is routable for the 1st child SA established. 

Since you are using Routebased VPN with specific traffic selectors (local remote subnets) configured, it still needs a XFRM IP address for your usecase. 

Below are some additional steps required. 

1) Configure the XFRM Interface IP address ( it is still required although not mandatory for normal RBVPN with traffic selector usecases)  on both the Nodes  in the same subnet (preferably else routing to be configured). 
1) Add the Local XFRM  Interface IP  into the local  Subnet for the respective XG nodes

2) Add the Remote XFRM  Interface IP  into the remote  Subnet for the respective XG nodes.

3) In the Firewall rule, add the linked NAT rule with MASQ 

4) Traffic will use  XFRM IP  as source address at the destination. 

Regards,
Vamshi

I can see how that would solve the issue but I assume this will NAT and MASQ all the tunnel traffic and that is not a suitable solution for us as we need to be able to identify the source IPs for all remote endpoints over the VPN.

hi JasP ,  You can fine tune MASQ setting for specific source and destination. 
Option is to use a NAT rule with the "Translation settings" specific to the original source and destination [ IP or subnet] and translation set as MASQ. 

Regards,
Vamshi

Hi vamshi d 

I got it working with your suggestions. One thing needed changing which I mention for anybody else who comes across this discussion.

As it is internal traffic that I am interested in (syslog), you can't use NAT/MASQ firewall rules, you have to use 'set advanced-firewall sys-traffic-nat' instead via the console.

e.g. set advanced-firewall sys-traffic-nat add destination 192.168.1.25 snatip 172.16.1.1
where snatip is the local XFRM IP

All internal XG traffic passing through the IPsec VPN tunnel then appears to come from 172.16.1.1

Hi JasP , Glad to know my suggestions helped and you have got it working.

I missed the point that syslog traffic is from the XG itself. You are right that we need sys-traffic-nat as your requirement is for  the system(internal) generated traffic as it doesn't traverse the firewall rules.

Thanks for sharing the updated solution which will help for issues with similar requirement. 

Regards,

Vamshi

Hi JasP , Glad to know my suggestions helped and you have got it working.

I missed the point that syslog traffic is from the XG itself. You are right that we need sys-traffic-nat as your requirement is for  the system(internal) generated traffic as it doesn't traverse the firewall rules.

Thanks for sharing the updated solution which will help for issues with similar requirement. 

Regards,

Vamshi