On 2017-03-16, Sébastien Morand <[email protected]> wrote: > Thank you Mike for your answer. There is nothing more like you said. > Actually we succeed in phase 1 but not in phase 2. .. > It's look like good to me and conform to the provided specs. Phase 1 is ok > but no phase 2: > 155851.640374 Default ipsec_validate_id_information: dubious ID information > accepted > 155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154, > responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142 > 155918.682560 Default transport_send_messages: giving up on exchange > from-10.85.98.16/29-to-10.249.0.0/21, no response from peer > 80.125.165.142:4500 .. > so it means to me they don't answer to my packet but I don't know why : > 16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp > v1.0 exchange QUICK_MODE encrypted .. > Any idea what can be done or a way to get more information on what's going > on? They are using CISCO 6509 with IOS 12.2-33.SXH3a.
isakmpd sends the wrong encapsulation mode (always TUNNEL, not UDP_ENCAPSULATED_TUNNEL). But also last time I tried this (in 2011) Cisco hadn't caught up with the RFC and actually required the UDP_ENCAPSULATED_TUNNEL_DRAFT value from the draft nat-t spec. This would cause a phase 2 failure, an ASA reports it like "[IKEv1]Phase 2 failure: Mismatched attribute types for class Encapsulation Mode: Rcv'd: Tunnel Cfg'd: UDP Tunnel(NAT-T)" Here's an old post about it with an isakmpd diff that was working against Cisco. What I don't know is whether it harms interop with anything else. http://marc.info/?l=openbsd-tech&m=131244805816474
