Azure site-to-site VPN route-based tunnel connectivity issues

It looks like I need to create some routes from the console, following this guide: https://support.sophos.com/support/s/article/KB-000035839?language=en_US.

I'm trying to run the command 

console> system ipsec_route add net 172.16.10.0/255.255.255.0 tunnelname nlgz03ashare0101

Where 172.16.10.0/24 is the Azure VNet's address space (not subnet) and nlgz03ashare0101 is the name of the IPSec connection, however, the command does not like the tunnelname given. According to the linked documentation tab + tab should populate the tunnelname. 

The error is:

% Error: Unknown Parameter 'nlgz03ashare0101'

Where does the tunnel name come from?

Thanks in advance.

Hi woter324: Thank you for reaching out to the Sophos community team. The configuration KBA which you used for a tunnel with AWS is RBVPN (Route-based VPN OR tunnel Interface based VPN tunnel) type tunnel and in the last comment the KBA or command to add the IPsec manual route, you are using is generally used with PBVPN (Policy-based IPsec tunnels).

So with RBVPN to forward traffic over VPN for remote end destination either static route over xfrm Interface should help or SD-WAN rule will help.

This section will help to get more info on same:https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/VPN/SiteToSiteVPN/VPNCreateRouteBasedVPN/index.html#add-firewall-rules-ho

Reference Video Link: 

RBVPN https://www.youtube.com/watch?v=o4NB1nHBOsE

SD-WAN : https://www.youtube.com/watch?v=TolZsFNbBuM

Try to do double tap to autocomplete the name. 

Hi Marccel Haus: Thanks for the update, glad to know the steps helped you.

Thank you Vishal_R for replying and clearing up route-based vs Policy-based VPNs.

I am definitely using route-based.

I've watched the video. I've deleted the static route and created the following SD-WAN route:

Incoming interface: Port2.40 - 172.16.40.1 (the source of my pings)

Source network: VLAN40 (Network 172.16.40.1/28)

Destination network: 192.168.10.1/24 (The address space of the Azure VNET)

Everything else is "ANY"

I created the primary gateway:

Gateway IP: None

Interface: xfrm1-169.254.0.1 (The IP given in the downloaded config (Step 5 (6)).

I ran the command "set routing sd-wan-policy-route reply-packet enable" from the XGs console.

The result of these changes is that I can still ping from the Azure node to my local network, but I cannot ping from on-prem to Azure.

Doing a traceroute from my on-prem source to a node on the Azure VNET (192.168.10.4) only gets as far as the default gateway (172.16.40.1). To me, this means that even if there was a Network Security Group or some Ubuntu firewall in the way, it's not getting that far as the ping packets aren't being given the route.

I am seeing the firewall allow the outbound ICMP packets.

UPDATE

Looking a little deeper, from the advanced shell, my routes look like this:

SFVH_SO01_SFOS 18.0.4 MR-4# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.10.0     0.0.0.0         255.255.255.240 U     0      0        0 Port2.10
172.16.20.16    0.0.0.0         255.255.255.248 U     0      0        0 Port2.23
172.16.40.0     0.0.0.0         255.255.255.192 U     0      0        0 Port2.40
172.16.50.0     0.0.0.0         255.255.255.0   U     0      0        0 Port2.50
172.16.50.0     0.0.0.0         255.255.255.0   U     0      0        0 Port1
172.16.55.0     0.0.0.0         255.255.255.240 U     0      0        0 Port2.55
172.16.60.0     0.0.0.0         255.255.255.0   U     0      0        0 Port2.60
172.16.65.0     0.0.0.0         255.255.255.192 U     0      0        0 Port2.65
10.255.0.0      0.0.0.0         255.255.255.0   U     0      0        0 GuestAP
52.149.73.23    0.0.0.0         255.255.255.255 UH    0      0        0 Port3_ppp
169.254.0.0     0.0.0.0         255.255.255.252 U     0      0        0 xfrm1
172.16.30.16    0.0.0.0         255.255.255.248 U     0      0        0 Port2.30
172.16.35.0     0.0.0.0         255.255.255.224 U     0      0        0 Port2.35
172.16.81.16    0.0.0.0         255.255.255.240 U     0      0        0 Port2.81
172.16.100.0    0.0.0.0         255.255.255.248 U     0      0        0 Port2.100

I have disabled the SD-WAN routes and created the static route again:

Maybe I don't understand what is going on, but should the gateway for 169.254.0.0 (xfrm1 interface) entry not be 169.254.0.2. Doesn't 0.0.0.0 = Internet/WAN?

Any ideas on anything else I can try, please?

Many thanks.

Hi woter324: Thanks for the latest update and following the articles, If PING is still not working then would suggest opening a support case to work on it and to validate more further on the config part and packet capture etc.

Hi Vishal_R,

Unfortunately, this is the home edition license and I can't raise a support request in the traditional sense, so this is my support case :-)

Thanks

I've just upgraded to 18.5.1 MR-1, which I hoped would fix my issues, but alas, not.

I had made a mistake in the unicast route, where I was specifying the VTI IP address. My routes now look like:

SFVH_SO01_SFOS 18.5.1 MR-1-Build326# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
172.16.10.0     0.0.0.0         255.255.255.240 U     0      0        0 Port2.10
172.16.20.16    0.0.0.0         255.255.255.248 U     0      0        0 Port2.23
172.16.40.0     0.0.0.0         255.255.255.192 U     0      0        0 Port2.40
172.16.50.0     0.0.0.0         255.255.255.0   U     0      0        0 Port2.50
172.16.50.0     0.0.0.0         255.255.255.0   U     0      0        0 Port1
172.16.55.0     0.0.0.0         255.255.255.240 U     0      0        0 Port2.55
172.16.60.0     0.0.0.0         255.255.255.0   U     0      0        0 Port2.60
172.16.65.0     0.0.0.0         255.255.255.192 U     0      0        0 Port2.65
172.16.200.0    0.0.0.0         255.255.255.0   U     0      0        0 xfrm1
10.255.0.0      0.0.0.0         255.255.255.0   U     0      0        0 GuestAP
52.149.73.23    0.0.0.0         255.255.255.255 UH    0      0        0 Port3_ppp
169.254.0.0     0.0.0.0         255.255.255.252 U     0      0        0 xfrm1
172.16.30.16    0.0.0.0         255.255.255.248 U     0      0        0 Port2.30
172.16.35.0     0.0.0.0         255.255.255.224 U     0      0        0 Port2.35
172.16.81.16    0.0.0.0         255.255.255.240 U     0      0        0 Port2.81
172.16.100.0    0.0.0.0         255.255.255.248 U     0      0        0 Port2.100

There are 2 xfrm1 entries and line 12 now shows the network of my Azure VNET's address space.

If I add a gateway to the unicast route of 169.254.0.2, then the gateway in the route shows the same IP.

With or without the gateway, I can ping from Azure to on-prem, but still, not the other way.

I have built a Windows server, where I know the OS firewall is off, just to rule out any Ubuntu issues.

I have also created SD-WAN routes removing the unicast route which was shown in the video as suggested by Vishal_R.

These look like this:

The gateway looks like this:

Again, with this config, I can ping from Azure, but not from on-prem.

I notice that adding the Gateway IP of 169.254.0.2 stops me from pinging from Azure.

I am not 100% sure the outbound routes are correct. I know the inbound one is correct as when it's disabled, I cannot ping, so I have applied logic to reverse the config for outbound.

I've also upgraded the Azure VPN SKU from basic to Standard - just in case this causes an issue.

A trace route from my laptop to an Azure VM only shows one hop - to my local network's gateway.

As I said, Sophos support is not an option, therefore, could anyone confirm if the route table above looks ok, or whether the xfrm1 gateway should be going out over the gateway entered in the Unicast Route settings? ie 169.254.0.2. Also, if anyone has any ideas on things to look at, I will be very grateful if you could share.

Thank you.

About six months ago, I couldn't ping from local to remote after setting up a route-based, IPSEC VPN (Tunnel Interface). At the time I gave up and set up Windows as a router to get around the problem. I've since had to revisit and solve the problem properly.

It appears that this is quite a common issue, so, although my original post has been locked  , I'm creating a new one with the solution.

DominicRemigio provided a step-by-step guide here for setting up a VPN between XG and Azure.

In the end, it was down to badly configured NAT'ing. During a prior upgrade, Sophos changed the way NAT'ing behaved and the upgrade process automatically created a bunch of NAT rules. Things seemed to work, so I left them as they were. (I'm not blaming Sophos. It was my fault).

What fixed the local > Azure ping issue was explicitly setting the Outbound Interface to my public interface. It was set to Any.

Steps:

1. Rules and policies.
2. NAT rules.
3. Select rule corresponding to VLAN that cannot ping.
4. Interface matching criteria > Outbound interface > <external facing port>.
5. Disable and reenable the VPN connection. 

Port C is my external interface and the local PC that couldn't ping the remote endpoint is on VLAN50.

I got some sporadic behaviour until I figured out any NAT rule changes had to be followed by reinitialising the connection.

Anyway, I hope the above may help others. In all fairness, it was a reply to a thread on this community that pointed me in the direction of NAT. (Sorry, Cannot find the post now.).