Routing through an IPSec VPN

Hello Thomas

Thanks for reaching out to Sophos Community

You may try to follow this KBA - How to create a hub and spoke IPsec VPN: https://support.sophos.com/support/s/article/KB-000035821?language=en_US

Additionally, you may also refer to this past Community thread that should be similar to your case:  Traffic from VPN to VPN via Sophos XG 

Regards,

Dear Raphael,

I managed to make it work this morning.

However, i'm now facing a weird thing: The following subnet 10.120.84.144/28 is not entirely responding to ping from my SS subnet.

For example, I can ping 10.120.84.148 and 10.120.84.150, but cannot ping 10.120.84.152.

This specific IP is obviously the most important in my scenario, so that's annoying. 

I cannot find this IP in a NAT rule ( i also checked the show advanced-firewall command using Putty) and I double checked everything, cannot find a good reason to explain this.

If you have a moment to help me on this, that would be really appreciated.

Thanks

Hello Thomas,

Glad to know it worked for you. 

Are there any deny/drop message you see destined for 10.120.84.152? What are the results when you traceroute to the said IP?

Could you also check if host firewall is enabled on the machine? 

Regards,

Hi Raphael,

I cannot see any drop/deny message in the logs.

In Diagnostics, I tried the traceroute to 10.120.84.152 but after 30 hops, it fails ( and it also fails for other IPs, but ping is fine!)

There's no host firewall enabled on the target machine.

Hello Thomas 

What does FW packet capture shows? under Diagnostics > Packet Capture 

From a source machine you could try to initiate a continious ping

Then on Packet Capture Configuration > Enter BPF String : dst host 10.120.84.152 and proto ICMP

If you happen to see any traffic, could you check the 'Status' on the captured packet section and also if there's any FW ID, NAT ID associated to it. 

Regards,

Hi Raphael,

I made several packet capture tests while running ping -t

If I ping 10.120.84.148 or 10.120.84.150, it works as expected and I can see everything is fine.

If I do the same test but pinging 10.120.84.152, the traffic is dropped due to my Rule #17 ( DROP src ANY dest WAN services ANY), while it should be allowed ( as I allow 10.120.84.144/28, which includes 10.120.84.152).

For me, this is a Sophos OS bug. I had no opportunity to reboot the router yet, but i plan to do it as soon as I can and test again.

Thanks for the information. Could you let us know results after your schedule reboot. If it still doesn't work as expected, kindly open a support case for this to be further investigated and kindly share with us the caseID here on this thread. 

Thank you

@Thomasb74, when you are pinging from 172.42.23.0/24 subnet client to 10.120.84.152, please check if the tcpdump on RR is egressing any esp packet (tcpdump -n esp  or tcpdump -n port 500 or port 4500).  If the esp (or esp over UDP) packets are not egressing to DC, you need to check on what happens to these packets; if the packets are egressing via the tunnel to DC, do you see the return esp packets back to RR from DC? if the return esp packets are not seen there could be issue with the DC.

Is it policy based or route based ipsec tunnel that you have between SS to RR and to DC ? 

@Thomasb74, when you are pinging from 172.42.23.0/24 subnet client to 10.120.84.152, please check if the tcpdump on RR is egressing any esp packet (tcpdump -n esp  or tcpdump -n port 500 or port 4500).  If the esp (or esp over UDP) packets are not egressing to DC, you need to check on what happens to these packets; if the packets are egressing via the tunnel to DC, do you see the return esp packets back to RR from DC? if the return esp packets are not seen there could be issue with the DC.

Is it policy based or route based ipsec tunnel that you have between SS to RR and to DC ? 

Hi,

I've checked this using tcpdump -n src 172.42.23.1 and dst 10.120.84.152 and running the ping from 172.42.23.1:

08:53:24.529361 ipsec0, IN: IP 172.42.23.1 > 10.120.84.152: ICMP echo request, id 32377, seq 0, length 64
08:53:25.529430 ipsec0, IN: IP 172.42.23.1 > 10.120.84.152: ICMP echo request, id 32377, seq 1, length 64
08:53:26.529572 ipsec0, IN: IP 172.42.23.1 > 10.120.84.152: ICMP echo request, id 32377, seq 2, length 64
08:53:27.529648 ipsec0, IN: IP 172.42.23.1 > 10.120.84.152: ICMP echo request, id 32377, seq 3, length 64

I did the same ping test but using tcpdump -n dst 172.42.23.1 and src 10.120.84.152:

Nothing is captured. 

So I believe there's an issue on DC, from what you wrote.