[j-nsp] Tunnel failing at "No propsal chosen" but works when target is another device

[Mattias Gyllenvarg]

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 <nick.ackroyd at gmail.com>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 juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>


-- 
*Med Vänliga Hälsningar*
*Mattias Gyllenvarg*