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!

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.
Parents
  • 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.

  • 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. ;-)

Reply
  • 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. ;-)

Children
No Data