Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 2 subscribers
  • Views 10000 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

Help! IPSec Site-to-Site is doing my head in!

Harro Verton

I've been going through every snippet about this subject I can find, but no answer as of yet. It's doing my head in, and my customer is starting to complain. :-(

Situation:

I need to setup a site-to-site VPN between our datacenter (which is protected by the UTM) and a site of a client, which uses a Draytek Vigor 2960 router/firewall.

UTM: 172.17.0.0/20
Draytek: 172.16.1.0/24

IPSec VPN is setup, connects without problems, all very well sofar. But not a single byte of traffic goes through. On the Draytek I can see traffic entering the tunnel, but 0 packets come back. On the UTM, I don't have a virtual interface I can check, but tcpdump sees no packets coming in.

Since the tunnel itself is ok, and I don't see any issues at the Draytek end (firewall is open, routes are created fine, traffic enters the tunnel), I started to focus on the UTM. I tried automatic and manual firewall rules, with no result. After some further digging, I see that strongswan has created this route on the UTM:

172.16.1.0/24 dev eth0  proto ipsec  scope link  src 172.17.1.2

Where does it get this src address from, and why is that there? It's is the interface address of the UTM's eth2, which is an isolated internal interface containing the DC's admin workstations.

Any tips, anything I can debug?

TIA,
Harro



This thread was automatically locked due to age.
  • 0

    To add to the previous: the interface in the IPSec definition defined as the local interface is eth0, not eth2.

    I think this one is picked because it is the first interface in the network range defined on the VPN. I have defined 172.17.1.2 defined on the Draytek as the remote gateway, put I can't ping it from the Draytek (packets go into the tunnel, no response comes back). 

    Another update:

    If I try to ping the remote gateway from the UTM itself, I see the packets being reported by strongswan:

    000 #47: "S_REF_IpsSitMonitoring_0" STATE_QUICK_R2 (IPsec SA established); EVENT_SA_REPLACE in 535s; newest IPSEC; eroute owner; DPD active
    000 #47: "S_REF_IpsSitMonitoring_0" esp.a007c40b@x.x.101.25 (168 bytes, 38s ago) esp.99aebf66@y.y.10.2 (0 bytes); tunnel
    000 #41: "S_REF_IpsSitMonitoring_0" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 1772s; newest ISAKMP; DPD active
    000 #51: "S_REF_IpsSitMonitoring_0" STATE_MAIN_I1 (sent MI1, expecting MR1); EVENT_RETRANSMIT in 21s

    But zero bytes come back. On the other end, I see

    IPsec Tunnel: AES-SHA256 Auth y.y.10.2 via WAN1 172.17.0.0/20 36 3 0 0 1:38:14

     

    so no bytes coming in.

  • 0 in reply to Harro Verton

    Grmblll....

    Sorry for wasting your time reading and thinking about it. I've told the customer a zillion times what the policy definitions should be, but stuborn as he is, he kept on defining SHA1 instead of SHA256.

    Customer -> DC:

    PING 172.17.2.60 (172.17.2.60) 56(84) bytes of data.
    64 bytes from 172.17.2.60: icmp_seq=1 ttl=62 time=17.1 ms
    ^C
    --- 172.17.2.60 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 17.154/17.154/17.154/0.000 ms

    DC -> Customer:

    PING 172.16.1.31 (172.16.1.31) 56(84) bytes of data.
    64 bytes from 172.16.1.31: icmp_seq=1 ttl=63 time=16.3 ms
    ^C
    --- 172.16.1.31 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 16.339/16.339/16.339/0.000 ms

    Me is a happy bunny now. ;-)

  • 0

    "On the Draytek I can see traffic entering the tunnel, but 0 packets come back." - This indicates a routing problem on their side.

    "On the UTM, I don't have a virtual interface I can check" - Try the following to watch inside the tunnel of an IPsec Connection named "My Customer":

    • # cc get_object_by_name 'ipsec_connection' 'site_to_site' 'My Customer'|grep 'ref'
      • That should tell you that the REF_ is something like REF_IpsSitMyCustomer
    • # espdump -n --conn REF_IpsSitMyCustomer -vv

    That scope link looks normal to me, so I don't think you're the problem.

    Cheers - Bob
    PS After I posted this, I saw that you'd already solved the problem yourself - bravo!

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    No worries.

    As always, I've learned something I didn't know from your reply. Filing "espdump" in  my cheatsheet.

    Thanks, Bob!!

Unfiltered HTML