Hi all, sorry forgot to send to the group too:
Hi Mattias, is the tunnel interface (st0.0) in a security zone? I remember i got this phase 1 error message when not assigning the zone and it drove me crazy because of the misleading error message. regards, Nick -- Nicholas Ackroyd Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Monday, 25. November 2013 at 11:53, Mattias Gyllenvarg wrote: > Hi All > > This is my first post to j-nsp, since this is my first encounter with > anything "advanced" on a juniper platform. > JTAC is working on this as well, but I am hoping for a snappy response from > the community. > > The issue is a IPsec tunnel that will not establish with one device as the > HUB but works with a different device. > > Spoke is SRX210 cluster > > Hub is SRX240 cluster > > Replacement Hub is a stand-alone SRX210 > > Junos is 12.1X44-D20.3 across the board. > > > > Relevant config for HUB240 > > ike { > proposal <cleaned>-IKE-Proposal { > authentication-method rsa-signatures; > dh-group group2; > authentication-algorithm sha1; > encryption-algorithm aes-128-cbc; > } > policy <cleaned>-IKE-Policy { > mode aggressive; > proposals <cleaned>-IKE-Proposal; > certificate { > local-certificate XXXX-HUB; > } > } > gateway Euro-Hub { > ike-policy <cleaned>-IKE-Policy; > dynamic { > distinguished-name { > wildcard "O=<cleaned>"; > } > } > dead-peer-detection { > always-send; > interval 10; > threshold 3; > } > local-identity distinguished-name; > external-interface reth1; > } > } > ipsec { > proposal <cleaned>-IPsec-Proposal { > protocol esp; > authentication-algorithm hmac-md5-96; > encryption-algorithm des-cbc; > } > policy <cleaned>-VPN-Policy { > perfect-forward-secrecy { > keys group14; > } > proposals <cleaned>-IPsec-Proposal; > } > vpn hub-to-spoke-vpn { > bind-interface st0.0; > ike { > gateway Euro-Hub; > ipsec-policy <cleaned>-VPN-Policy; > } > } > } > > int reth1 > unit 0 { > family inet { > address x.x.x.71/24; > address x.x.x.11/24; > > > security-zone untrust { > screen untrust-screen; > host-inbound-traffic { > system-services { > ike; > ping; > traceroute; > ssh; > } > } > interfaces { > reth1.0 { > host-inbound-traffic { > system-services { > ike; > ping; > traceroute; > ssh; > > > nat > static { > rule-set XXXX-DMZ { > from zone untrust; > rule to-dmz { > match { > destination-address <cleaned>.71/32; > } > then { > static-nat { > prefix { > 10.<cleaned>.71/32; > > > Difference in config from working sollution is. > > No cluster, so no reth. > No secondary IP on tunnel externel interface. (removed this with no effect) > A static nat for the secondary address. > > Proposals have been verified several times. Deleted and re-added, > 240cluster has been rebooted. > > Is there any known issue that with this kind of setup for the SRX240? I > have found none. > > From what I can tell in the kmd debug-log the work setup validates with DN > when the "Address based phase 1 SA-CFG lookup failed" fails. The 240 does > not seem to try to validate DN. > > Snippet from log where it fails. > > iked_pm_phase1_sa_cfg_lookup_by_addr: Address based phase 1 SA-CFG lookup > failed for local:x.x.x.11, remote:y.y.y.y. IKEv1 > iked_pm_ike_spd_select_ike_sa failed. rc 1, error_code: No proposal chosen > ikev2_fb_spd_select_sa_cb: IKEv2 SA select failed with error No proposal > chosen (neg de5800) > ike_isakmp_sa_reply: Start > > -- > *Best Regards* > *Mattias Gyllenvarg* > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > (mailto:juniper-nsp@puck.nether.net) > https://puck.nether.net/mailman/listinfo/juniper-nsp > > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp