One tunnel by itself works fine, but switching on the second router, and they are 'colliding' somehow at the ipsec negotiation layer. UTM is getting confused.
With the UTM in respond mode, it's matching VPN ID = any. So the only thing that really separates them is the preshared keys, which are unique to each tunnel. We have PSK probing switched on. I can see UTM is trying the different secrets in turn.
But something is still going wrong as the second site to site tunnel won't come up unless we disable the first one. (Actually had to turn off the router in fact!)
The log is somewhat confusing to follow, but here is a section that illustrates what's going on:
2013:05:20-06:11:17 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: responding to Main Mode from unknown peer w.x.y.z
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: received Vendor ID payload [Dead Peer Detection]
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: ignoring Vendor ID payload [a0eb1c7926ecb7bb6ea2b337065b9476]
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: received Vendor ID payload [XAUTH]
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: next payload type of ISAKMP Identification Payload has an unknown value: 151
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: Preshared secret failed to decrypt message. Trying next one.
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: next payload type of ISAKMP Identification Payload has an unknown value: 156
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: Preshared secret failed to decrypt message. Trying next one.
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: ignoring informational payload, type IPSEC_INITIAL_CONTACT
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[2] w.x.y.z #884: Peer ID is ID_IPV4_ADDR: 'a.b.c.d'
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[3] w.x.y.z #884: deleting connection "S_REF_IpsSitAutest_0"[2] instance with peer w.x.y.z {isakmp=#0/ipsec=#0}
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[3] w.x.y.z #884: Dead Peer Detection (RFC 3706) enabled
2013:05:20-06:11:18 vpn pluto[17562]: "S_REF_IpsSitAutest_0"[3] w.x.y.z #884: sent MR3, ISAKMP SA established
What's concerning about this is that the reference to S_REF_IpsSitAutest is the descriptor for the _other_ tunnel, not the one associated with IP w.x.y.z.
We'll have to do some more testing to try and pin this down, but can anyone confirm, so long as the local subnets behind each remote gw are non overlapping, is there any reason we shouldn't be able to make this work using preshared keys?
As I said, with only one of the two routers powered up, either one, the tunnel works fine.
This thread was automatically locked due to age.
