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
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.
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…
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-hoReference Video Link: RBVPN https://www.youtube.com/watch?v=o4NB1nHBOsESD-WAN : https://www.youtube.com/watch?v=TolZsFNbBuM
Regards,Vishal RanpariyaTechnical Account Manager | Sophos Technical SupportSophos Support Videos | Knowledge Base | @SophosSupport | Sign up for SMS Alerts | If a post solves your question use the 'This helped me' link.
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.
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
188.8.131.52 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?
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.
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 :-)