Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 40 subscribers
  • Views 3266 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

Routing through an IPSec VPN

Thomasb74

Hi,

First of all, I tried to find existing discussions about the issue i'm facing but i'm not 100% sure I've searched/used the right keywords.

Let me explain:

I have 3 sites (let's call those SS, RR and DC).

SS subnet is: 172.42.23.0/24

RR subnet is:172.42.21.0/24

DC subnet is: 10.120.84.144/28

I have a site to siteVPN between SS and RR, which works fine, and another one between RR and DC, which also works fine for now.

Each VPN has the 2 endpoints subnets added to local/remote subnets, as it should. 

I want to allow traffic from SS to access DC, through RR. I dont want to mount another VPN from SS to DC, as the DC router is not mine and I cannot manage it directly..

I've asked our IT contact to allow the SS subnet to the "authorized/advertised" subnets on the DC config, which was done, and i've also added it on my side, on the RR DC config.

Despite that, this is not working and i'm stuck at the moment. 

The SS XG230 can ping my RR XG230, my RR router can ping the remote endpoint, but the SS XG230 cannot trace route, nor ping the DC endpoint.

Could you please assist? 

Thanks !



This thread was automatically locked due to age.
Parents
  • 0

    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,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Raphael Alganes

    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

  • 0 in reply to Thomasb74

    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,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Raphael Alganes

    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.

  • 0 in reply to Thomasb74

    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,

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Raphael Alganes

    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.

  • 0 in reply to Thomasb74

    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

    Raphael Alganes
    Community Support Engineer | Sophos Technical Support
    Sophos Support Videos | Product Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.

  • 0 in reply to Thomasb74

    @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 ? 

  • 0 in reply to Raphael Alganes

    Hi Raphael,

    I've rebooted RR and SS routers ( I do not manage DC router). Still the same, packets are dropped by the default DROP rule #0 when pinging 10.120.84.152, while everything works fine when pinging 10.120.84.148.

    I'll open a support case, thanks a lot for your help.

  • 0 in reply to Raphael Alganes

    Hi Raphael,

    I've rebooted RR and SS routers ( I do not manage DC router). Still the same, packets are dropped by the default DROP rule #0 when pinging 10.120.84.152, while everything works fine when pinging 10.120.84.148.

    I'll open a support case, thanks a lot for your help.

  • 0 in reply to Sreenivasulu Naidu

    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. 

Reply
  • 0 in reply to Sreenivasulu Naidu

    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. 

Children
No Data
Unfiltered HTML