Guest User!

You are not Sophos Staff.

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

access through 2 vpn(hops) problems

hello,

i'm having an issue routing traffic through 2 vpn links and i can't find a solution, here's the setup

lan A 10.10.20.x/24 ---vpn1--- lan B 10.10.10.x/24---vpn2--- lan C 192.168.3.x/24

vpn1 is a sophos xg 16.5 mr3

vpn2 is a utm 9.411

i need the computers on lan A to access lan C.

A to B works perfect, B to C also works perfect

 

steps i did to try and solve this problem:

added a policy route on XG for 192.168.3.x/24 gateway 10.10.10.15 which is the utm ip

on the utm i added  snat for traffic from lan A to lan C snat oriign ip as internal lan ip 10.10.10.15

it doesn't works, on a A station the traffic does not even reach the UTM, the XG responds with destination unreachable

i added a manual route on a PC to go through utm, same error but now takes much more time for the tracert to show the failure

i disabled the SNAT rule, no change

added a ipsec route on XG: system ipsec_route add net 192.168.3.0/24 tunnelname vpn1

no change, even pinging from the XG console fails

added a 1:1 snat rule, same

i can't find how to add a static route as it forces the gateway to be in the same network as one of the interfaces(which it cannot be) and indeed the route table shows no path to C network

 

i'm not seeing any hits on the fw logs even.

 

any ideas?

 



This thread was automatically locked due to age.
  • Mast_01,

    use traceroute command, tcpdump and drop-packet-capture to understand what's going on. Share the results here.

    Regards

  • Luk,

    i have no dropped packets on the XG, this is the capture of the tcpdump:

    CR15iNG_AM02_SFOS 16.05.3 MR-3# tcpdump -nn dst 192.168.3.50
    tcpdump: Starting Packet Dump
    15:35:30.519068 PortA, IN: IP 10.10.20.10.137 > 192.168.3.50.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
    15:35:32.024054 PortA, IN: IP 10.10.20.10.137 > 192.168.3.50.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
    15:35:33.531098 PortA, IN: IP 10.10.20.10.137 > 192.168.3.50.137: NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
    15:35:35.041064 PortA, IN: IP 10.10.20.10 > 192.168.3.50: ICMP echo request, id 1, seq 3196, length 72
    15:35:55.456102 PortA, IN: IP 10.10.20.10.52540 > 192.168.3.50.3389: Flags [S], seq 3013558745, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    15:35:58.456126 PortA, IN: IP 10.10.20.10.52540 > 192.168.3.50.3389: Flags [S], seq 3013558745, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
    15:36:04.457486 PortA, IN: IP 10.10.20.10.52540 > 192.168.3.50.3389: Flags [S], seq 3013558745, win 8192, options [mss 1460,nop,nop,sackOK], length 0
    ^C
    7 packets captured
    7 packets received by filter
    0 packets dropped by kernel

  • Can you share the output of route -n command from advanced shell?

    Also traceroute to 192.168.3.50

    Thanks

  • routes:

    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
    10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 ipsec0
    10.10.20.0      0.0.0.0         255.255.255.0   U     0      0        0 PortA
    10.255.0.0      0.0.0.0         255.255.255.0   U     0      0        0 GuestAP
    190.x.x.x   0.0.0.0         255.255.255.0   U     0      0        0 PortB
    192.168.30.0    0.0.0.0         255.255.255.0   U     0      0        0 PortA.10

    portB is wan

    porta.10 is a wifi vlan

     

    tracert insta-fails:

    tracert -d 192.168.3.50

    Traza a 192.168.3.50 sobre caminos de 30 saltos como máximo.

      1  10.10.20.1  informes: Red de destino inaccesible. (destination unreachable)

    Traza completa.

     

     

  • Mast_01,

    the network 192.168.3.0 is not inside the routing table so traffic is sent to internet.

    Check again the static routing. Did you add the network 192.168.3.0 inside the Site to site remote networks on XG?

    Regards

  • HI Mast_01, 

    I believe that the issue is with the VPN policy . 

    Suggestion: Site A to C

    Site A to B

    Local Network <LAN network >

    Remote Network <LAN Network of C and LAN network of B>

    Site B to C 

    Local Network <LAN network of A and B >

    Remote Network <Remote Network of C>

     

    Rules Needed at site A and C

    LAN-VPN and VPN-LAN

    Rules Needed at site B

    LAN-VPN , VPN-LAN and VPN-VPN

  • the rules at site C cannot be modified in any way of shape and cannot be redefined for anything but site B lan, that's why i used a SNAT and since i'm not doing strict routing on the tunnel, the SNAT should work, a masquerade rule should work as well (or better put, why isn't it working?).

    i'll test by expanding the tunnel definitions on the A to B VPN to include the C network, but i still need to snat this

  • Hi Mast_01, 

    As you are facing issue with communicating Site A and C , you may need to take a TCP dump on all three sites. You may conduct a Ping test from the system in a LAN and not from the device.  Monitor the ping traffic from all 3 locations A,B and C.

    This should give us an idea on why the traffic was not routed and not working as you would expect it should.