Hi Mr Ackroyd Actually it was not, it was before but I removed it when I removed the st interface to re apply it. I have since then fixed the original issue and now got through IKE and have it working.
Thank you. Mattias Gyllenvarg On Mon, Nov 25, 2013 at 2:32 PM, Nicholas Ackroyd <[email protected]>wrote: > 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp > > > -- *Med Vänliga Hälsningar* *Mattias Gyllenvarg* _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
