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

[Nicholas Ackroyd]

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 at puck.nether.net (mailto:juniper-nsp at puck.nether.net)
> https://puck.nether.net/mailman/listinfo/juniper-nsp
> 
>