Thread Info
  • State Verified Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 8619 views
  • Users 0 members are here
Options
Suggested
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

woter324

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.
Parents
  • 0

    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.

  • 0 in reply to woter324

    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.

  • in reply to Vishal_R
    This reply was deleted.
  • 0 in reply to Marccel Haus

    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.

  • 0 in reply to Vishal_R

    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.

Reply
  • 0 in reply to Vishal_R

    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.

Children
  • 0 in reply to woter324

    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.

  • 0 in reply to Vishal_R

    Hi ,

    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

  • 0 in reply to woter324

    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 .

    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.

Unfiltered HTML