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

CISCO ASA 5515 to UTM 9.4 (SG230) VPN Peer ID

 Our connection seems to be completing phase 1, but is failing on a matched/mismatched Pair ID. The thing is that the pair id actually matches, but the log says that it doesn't, but shows the same two words there.

I don't have access to the actual cisco box, it is with an external vendor. Here are the respective logs.

CISCO LOG

Mar 31 2017 08:21:08: %ASA-5-713201: Group = 1.1.1.1, IP = 1.1.1.1, Duplicate Phase 1 packet detected. Retransmitting last packet.
Mar 31 2017 08:21:08: %ASA-6-713905: Group =1.1.1.1, IP =1.1.1.1, P1 Retransmit msg dispatched to MM FSM
Mar 31 2017 08:21:08: %ASA-7-713906: Received unexpected event EV_RESEND_MSG in state MM_REKEY_DONE_H2
Mar 31 2017 08:20:58: %ASA-5-713068: Group =1.1.1.1, IP =1.1.1.1, Received non-routine Notify message: Invalid ID info (18)

SOPHOS LOG
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: ignoring Vendor ID payload [FRAGMENTATION c0000000]
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: enabling possible NAT-traversal with method RFC 3947
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: ignoring Vendor ID payload [Cisco-Unity]
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: received Vendor ID payload [XAUTH]
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: ignoring Vendor ID payload [26af64ae1ce2e355e599171584afb948]
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: received Vendor ID payload [Dead Peer Detection]
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: Peer ID is ID_KEY_ID: 'abc'
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: we require peer to have ID 'abc', but peer declares 'abc'
2017:03:31-10:06:52 50 pluto[3800]: "S_KWIK-2" #1: sending encrypted notification INVALID_ID_INFORMATION to 2.2.2.2:4500



This thread was automatically locked due to age.
Parents
  • Hi, JF, and welcome to the UTM Community!

    Could you draw us a simple diagram showing the IPs involved?  You lost me when you mentioned a Full NAT.

    Cheers - Bob

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

    Thanks Bob. Here is the diagram, but the main issue is that the site to site VPN will not authenticate. Though the peer IDs match, the log says that they mismatch. The Peer ID is only 3 letters, not sure if that might be the problem.

  • Shot in the dark here but have you tried just leaving the VPN ID type as Ip address and leaving the VPN ID blank? I have some setup like that and they work?

     

    Not sure if these posts are relevant?

    They suggest that if a psk is used, you can only use the ip address as the vpn type id

    community.sophos.com/.../ipsec-vpn-id-question

    https://community.sophos.com/products/unified-threat-management/f/vpn-site-to-site-and-remote-access/54898/site-to-site---can-i-change-vpn-id

  • Hey Louis. Tried that, tried it again to paste the log...

    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: ignoring Vendor ID payload [FRAGMENTATION c0000000]
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: enabling possible NAT-traversal with method RFC 3947
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: ignoring Vendor ID payload [Cisco-Unity]
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: received Vendor ID payload [XAUTH]
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: ignoring Vendor ID payload [e57075983ea39b7e32ecac3b7a482c5f]
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: ignoring Vendor ID payload [Cisco VPN 3000 Series]
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: peer is NATed
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: received Vendor ID payload [Dead Peer Detection]
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: Peer ID is ID_KEY_ID: 'abc'
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: we require peer to have ID '2.2.2.2', but peer declares 'abc'
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: sending encrypted notification INVALID_ID_INFORMATION to 2.2.2.2:4500
    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: ignoring Delete SA payload: ISAKMP SA not established
     
    I am going to restart the UTM in the morning and see if we continue to get the mismatch error. This has also been escalated with Sophos support. In the meantime (as they look into it), I am going to ask the vendor to set up a second site to site VPN for me and try to establish a connection at a remote site that has a Sonicwall to see if I run into the same issues.
  • Looking at the links I sent, they appear to suggest that you need to get the peer to change it's ID type to IP address.

    They suggest that because you are using a PSK, the VPN ID type has to be IP address on the peer ie not hostname or email address as the UTM forces it to be the IP address only

  • So, the Full NAT is in the UTM and is just used to get traffic from external clients to the server and back.  Clearer now, but still not crystal...

    Is this simply an IPsec SA 'Internet = 1.1.1.1 <> 2.2.2.2 = 192.9.200.169'?  If so, then the simplest answer is to use Louis' suggestion.  If 1.1.1.1 and 2.2.2.2 are not the endpoints, then it's a little trickier.

    I don't understand the reason to try to use a non-existent hostname for the VPN ID.  Are you certain the following line from your log above is correctly reflecting what you see in the log that's had private details obfuscated?

    2017:04:02-15:40:48 50 pluto[22287]: "S_KWIK-2" #1383: we require peer to have ID '2.2.2.2', but peer declares 'abc'

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob,

    to me it looks that simple too. But according to the links I sent, the UTM by design only allows the VPN ID type to be ip address due to using a PSK.
    According to them, if using a PSK it does not matter what you set, the UTM will overwrite it and default to the IP address.

    It suggests that you may need to use certs to use a VPN ID of host or email.

  • Hi Bob,

     

    Yes, the log line is correct. If I leave it blank, the Sophos requires the peer to have the 2.2.2.2 (WAN address of the Cisco). If I enter 192.9.200.169, I get the following:

    we require peer to have ID '192.9.200.169', but peer declares 'abc'

     The abc is required by the Cisco (whose policies I have little/no control over). They have 40 some other clients that can connect without error with the abc identifier.

     The NATs will work, it is the initial connection that remains the issue. I'll keep at it.

     Thanks,

    Jon

  • I'll look into the certs idea.

    Thanks,

    Jon

  • Hi JF1,

    did you have defined under s2svpn / ipsec / advanced Preshared Key Settings the VPN ID type "hostname" and as vpn id "abc"?

    regards

    mod

  • Hello,

    Adding the ID in advanced has no effect, the same errors persist in the log.

  • Hi JF1,

    "we require peer to have ID 'abc', but peer declares 'abc'" sounds like, one site has VPN ID "abc" configured with wrong VPN ID Type. (ID "abc" and Type "IP-Address"). Don't know, if this is possible on cisco site.

    regards

    mod

Reply
  • Hi JF1,

    "we require peer to have ID 'abc', but peer declares 'abc'" sounds like, one site has VPN ID "abc" configured with wrong VPN ID Type. (ID "abc" and Type "IP-Address"). Don't know, if this is possible on cisco site.

    regards

    mod

Children
No Data