This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Hi,

I have created a site-to-site IPSec VPN between my XG and Azure.

The tunnel is up, confirmed both sides and I can connect from Azure to local, but not the other way around.

I followed this article to the letter: https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/126356/sophos-xg-firewall-v18-to-azure-vpn-gateway-ipsec-connection.

I have multiple VLANs configured on my XG. I haven't done anything specific for those - not that I know if I need to. The firewall rule encompasses all the VLANs.

When testing connectivity from local to Azure, I can see the rule is allowed.

I have a gaping hole in my Azure NSG (ANY-ANY), both inbound and outbound.

The Azure endpoint is Ubuntu 20.04 LTS and as far as I know, all firewalls are off:

user@vm01:~$ sudo ufw status verbose
Status: inactive

Here is the main VPN config page:

I'm not particularly familiar with Ubuntu, so it may be something on the endpoint, however, I'd like to rule out XG's VPN config.

I read the note about the XG version and I am currently running on SFOS 18.0.4 MR-4. Can't upgrade just yet.

If anyone can think of anything I should try, please shout.

T.I.A



This thread was automatically locked due to age.

Top Replies

  • in reply to woter324 +3 suggested

    Hi : 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…

Parents
  • 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 : 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

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support

    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link.

  • This reply was deleted.
  • Hi : Thanks for the update, glad to know the steps helped you.

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support

    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link.

  • Thank you  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 : 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.

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support

    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link.

Reply Children