SRX Services Gateway
Reply
Contributor
bobjunga
Posts: 63
Registered: ‎02-29-2012
0

openswan to srx220h IPSEC tunnel problem

[ Edited ]

I am replacing a PIX with an SRX229h. I have several different VPN tunnel endpoints and getting the openswan endpoints working is driving me crazy.

 

Can anyon look at this data and give me some advice on what to do next?

 

The openswan server sends the first IKE phase 1 packet to the SRX and the SRX replies with "NO-PROPOSALS-CHOSEN".. That's seems like I just have the IKE proposals mis configured so that they don't match but I think that the packets copied below show that the proposal is correct.

 

I captured packets with wireshark of a sucessful VPN negotation with a racoon endpoint and then the openswan failed negotiation. The proposals sent by racoon and swan to the SRX in the first packets are identical. There are only two differences in the packates 1) the openswan sends two vendor ID sections at the end of the packet and 2) even though they both have only 1 proposal and transforn,  racoon numbers them "1" in swan numbers them "0".

 

On the SRX side, I have two almost identical "security ipsec vpn" sections and two almost identical "security ike gateway" sections for the two hosts. They only differ in the remote IPs and the remote subnet in the proxyids.

 

So the SRX is getting nearly identical packets for nearly identical vpns on the SRX but it accepts one and rejects the other.

 

In the SRX ike traceoptions log the first error I see is "Unable to find ike gateway as remote peer:n.n.149.63 is not recognized".  See full log below

 

 

 

 

May 31 00:24:18 ike_get_sa: Start, SA = { 9c6c7b2e 5b6cc980 - 00000000 00000000 } / 00000000, remote = 46.51.149.63:500
May 31 00:24:18 ike_sa_allocate: Start, SA = { 9c6c7b2e 5b6cc980 - 6848e7c3 4861e917 }
May 31 00:24:18 ike_init_isakmp_sa: Start, remote = n.n.149.63:500, initiator = 0
May 31 00:24:18 ike_decode_packet: Start
May 31 00:24:18 ike_decode_packet: Start, SA = { 9c6c7b2e 5b6cc980 - 6848e7c3 4861e917} / 00000000, nego = -1
May 31 00:24:18 ike_decode_payload_sa: Start
May 31 00:24:18 ike_decode_payload_t: Start, # trans = 1
May 31 00:24:18 ike_st_i_vid: VID[0..12] = 4f456d40 6b675346 ...
May 31 00:24:18 The remote server at n.n.149.63:500 is '4f 45 6d 40 6b 67 53 46 45 48 40 7f'
May 31 00:24:18 ike_st_i_vid: VID[0..16] = afcad713 68a1f1c9 ...
May 31 00:24:18 The remote server at n.n.149.63:500 is 'draft-ietf-ipsec-dpd-00.txt'
May 31 00:24:18 Not setting PMDATA_PEER_IS_OURS for n.n.149.63
May 31 00:24:18 ike_st_i_sa_proposal: Start
May 31 00:24:18 Local dest IP: ipv4(any:0,[0..3]=n.n.135.252)
May 31 00:24:18 Unable to find ike gateway as remote peer:n.n.149.63 is not recognized.
May 31 00:24:18 KMD_PM_P1_POLICY_LOOKUP_FAILURE: Policy lookup for Phase-1 [responder] failed for p1_local=ipv4(any:0,[0..3]=n.n.135.252) p1_remote=ipv4(any:0,[0..3]=n.n.149.63)
May 31 00:24:18 ike_isakmp_sa_reply: Start
May 31 00:24:18 ike_st_i_cr: Start
May 31 00:24:18 ike_st_i_cert: Start
May 31 00:24:18 ike_st_i_private: Start
May 31 00:24:18 ike_st_o_sa_values: Start
May 31 00:24:18 n.n.135.252:500 (Responder) <-> n.n.149.63:500 { 9c6c7b2e 5b6cc980 - 6848e7c3 4861e917 [-1] / 0x00000000 } IP; Error = No proposal chosen (14)
May 31 00:24:18 ike_alloc_negotiation: Start, SA = { 9c6c7b2e 5b6cc980 - 6848e7c3 4861e917}
May 31 00:24:18 ike_encode_packet: Start, SA = { 0x9c6c7b2e 5b6cc980 - 6848e7c3 4861e917 } / 2be83bf1, nego = 0
May 31 00:24:18 ike_send_packet: Start, send SA = { 9c6c7b2e 5b6cc980 - 6848e7c3 4861e917}, nego = 0, src=n.n.135.252:500, dst = n.n.149.63:500, routing table id = 0
May 31 00:24:18 ike_delete_negotiation: Start, SA = { 9c6c7b2e 5b6cc980 - 6848e7c3 4861e917}, nego = 0
May 31 00:24:18 ike_free_negotiation_info: Start, nego = 0
May 31 00:24:18 ike_free_negotiation: Start, nego = 0

 

 

This is the failed packet from the swan to the SRX (the one that produces the above log).

Internet Security Association and Key Management Protocol
    Initiator cookie: 752ABBEAD6DC02E2
    Responder cookie: 0000000000000000
    Next payload: Security Association (1)
    Version: 1.0
    Exchange type: Identity Protection (Main Mode) (2)
    Flags: 0x00
        .... ...0 = Not encrypted
        .... ..0. = No commit
        .... .0.. = No authentication
    Message ID: 0x00000000
    Length: 120
    Security Association payload
        Next payload: Vendor ID (13)
        Payload length: 56
        Domain of interpretation: IPSEC (1)
        Situation: IDENTITY (1)
        Proposal payload # 0
            Next payload: NONE (0)
            Payload length: 44
            Proposal number: 0
            Protocol ID: ISAKMP (1)
            SPI Size: 0
            Proposal transforms: 1
            Transform payload # 0
                Next payload: NONE (0)
                Payload length: 36
                Transform number: 0
                Transform ID: KEY_IKE (1)
                Life-Type (11): Seconds (1)
                Life-Duration (12): Duration-Value (86400)
                Encryption-Algorithm (1): 3DES-CBC (5)
                Hash-Algorithm (2): SHA (2)
                Authentication-Method (3): PSK (1)
                Group-Description (4): Alternate 1024-bit MODP group (2)
    Vendor ID: 4F456D406B6753464548407F
        Next payload: Vendor ID (13)
        Payload length: 16
        Vendor ID: 4F456D406B6753464548407F
    Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)
        Next payload: NONE (0)
        Payload length: 20
        Vendor ID: RFC 3706 Detecting Dead IKE Peers (DPD)

 

This is the successfull packet from the other similar racoon endpoint that works.

Internet Security Association and Key Management Protocol
    Initiator cookie: BB394BB7DA0AB5D8
    Responder cookie: 0000000000000000
    Next payload: Security Association (1)
    Version: 1.0
    Exchange type: Identity Protection (Main Mode) (2)
    Flags: 0x00
        .... ...0 = Not encrypted
        .... ..0. = No commit
        .... .0.. = No authentication
    Message ID: 0x00000000
    Length: 84
    Security Association payload
        Next payload: NONE (0)
        Payload length: 56
        Domain of interpretation: IPSEC (1)
        Situation: IDENTITY (1)
        Proposal payload # 1
            Next payload: NONE (0)
            Payload length: 44
            Proposal number: 1
            Protocol ID: ISAKMP (1)
            SPI Size: 0
            Proposal transforms: 1
            Transform payload # 1
                Next payload: NONE (0)
                Payload length: 36
                Transform number: 1
                Transform ID: KEY_IKE (1)
                Life-Type (11): Seconds (1)
                Life-Duration (12): Duration-Value (86400)
                Encryption-Algorithm (1): 3DES-CBC (5)
                Authentication-Method (3): PSK (1)
                Hash-Algorithm (2): SHA (2)
                Group-Description (4): Alternate 1024-bit MODP group (2)

 

Thanks,

 

--BobG

Contributor
bobjunga
Posts: 63
Registered: ‎02-29-2012
0

Re: openswan to srx220h IPSEC tunnel problem

[ Edited ]

More information....

 

The swan server is behind a static NATgateway so it thinks that its IP is a 10.* IP but hte SRX sees it as a Public IP. I manually set the proxyid from the swan serer to the public IP. The private IP does not apear in the first KE message that gets rejected by the SRX so I think that this can not be a problem yet. Maybe after I get past this first problem that wil become an issue.

 

It seems to me that even though the SRX's IKE response is "NO-PROPOSAL-CHOSEN", that message is misleading. I think that the error is that the SRX can not match up the incoming IP address with any configured gateways as indicated by the error in the ike traceoption log above. I don't know why that is though because the AmazonServersIKE clearly has the correct address set.

 

 

This is the SRX vpn config for the swan server that does not work (common config to both servers appear below)

 

vpn AmazonServerVPN {
    bind-interface st1.0;
    ike {
        gateway AmazonServersIKE;
        proxy-identity {
            local 172.17.24.0/21;
            remote 10.228.246.115/32;
            service any;
        }
        ipsec-policy IPSECPolicy-Default;
    }
    establish-tunnels immediately;
}

gateway AmazonServersIKE {
    ike-policy IKEPolicy-StaticSite;
    address n.n.149.63;
    external-interface reth1;
}

 

 

This is the SRX vpn config for the racoon server that works

vpn BGSiteVPN {
    bind-interface st0.0;
    ike {
        gateway BGSiteIKE;
        proxy-identity {
            local 172.17.24.0/21;
            remote 192.168.22.0/24;
            service any;
        }
        ipsec-policy IPSECPolicy-Default;
    }
    establish-tunnels on-traffic;
}

gateway BGSiteIKE {
    ike-policy IKEPolicy-StaticSite;
    address n.n.248.242;
    external-interface reth1;
}

 

This is the common config used by both vpn configs

policy IPSECPolicy-Default {
    perfect-forward-secrecy {
        keys group2;
    }
    proposals IPSECProposal-Default;
}

proposal IPSECProposal-Default {
    protocol esp;
    authentication-algorithm hmac-sha1-96;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 28800;
}

policy IKEPolicy-StaticSite {
    mode main;
    proposals IKEProposal-Default;
    pre-shared-key ascii-text "***************"; ## SECRET-DATA
}

proposal IKEProposal-Default {
    authentication-method pre-shared-keys;
    dh-group group2;
    authentication-algorithm sha1;
    encryption-algorithm 3des-cbc;
    lifetime-seconds 86400;
}

 

 

Distinguished Expert
MMcD
Posts: 628
Registered: ‎07-20-2010
0

Re: openswan to srx220h IPSEC tunnel problem

How does the trace look now when the correct gateway is responding to the SRX?

 

Are you still seeing remote peer unrecognized?

MMcD [JNCIP-SEC, JNCIS-ENT, CCNA, MCP]
____________________________________________________

[Please Mark My Solution Accepted if it Helped, Kudos are Appreciated Too]
Contributor
bobjunga
Posts: 63
Registered: ‎02-29-2012
0

Re: openswan to srx220h IPSEC tunnel problem

[ Edited ]

Below is the traceopts log of the sucessfull IKE start. I put a comment in the log where I think the failed negotiation emits its error.

 

Its curious to me that both logs have the line

ike_decode_payload_t: Start, # trans = 1

I believe this is the SRX reading the packet saying that it found a transform (whch is the meat of the proposal). They both call the found transform '1', but the transform number in the packet is '0', not '1' as it is in the good packet. It seems that swan(bad) starts numbering the payloads with 0 and racoon(good) starts numbering them with '1'. Maybe that is no big deal, but I wonder if that triggers a bug in the SRX that it misses the transform/propossal because the index is off by one.

 

SRX IKE traceopts log of successfull racoon IKE negotiation

May 31 10:46:30 gateway-th1 clear-log[6047]: logfile cleared
May 31 10:46:40 ike_get_sa: Start, SA = { a3953dda 73cf42e8 - 00000000 00000000 } / 00000000, remote = n.n.149.63:500
May 31 10:46:54 ike_get_sa: Start, SA = { af86e0cf 729d125b - 00000000 00000000 } / 00000000, remote = n.n.248.242:500
May 31 10:46:54 ike_sa_allocate: Start, SA = { af86e0cf 729d125b - a8029a79 ce4d1318 }
May 31 10:46:54 ike_init_isakmp_sa: Start, remote = n.n.248.242:500, initiator = 0
May 31 10:46:54 ike_decode_packet: Start
May 31 10:46:54 ike_decode_packet: Start, SA = { af86e0cf 729d125b - a8029a79 ce4d1318} / 00000000, nego = -1
May 31 10:46:54 ike_decode_payload_sa: Start
May 31 10:46:54 ike_decode_payload_t: Start, # trans = 1
May 31 10:46:54 ike_st_i_sa_proposal: Start
### My Comment #### I think that this is where the failed negotiation gets the error about not finding IP address
May 31 10:46:54 ike_isakmp_sa_reply: Start May 31 10:46:54 ike_st_i_cr: Start May 31 10:46:54 ike_st_i_cert: Start May 31 10:46:54 ike_st_i_private: Start May 31 10:46:54 ike_st_o_sa_values: Start May 31 10:46:54 NAT is enabled May 31 10:46:54 Advertizing DPD capability May 31 10:46:54 ike_policy_reply_isakmp_vendor_ids: Start May 31 10:46:54 ike_st_o_private: Start May 31 10:46:54 ike_policy_reply_private_payload_out: Start May 31 10:46:54 ike_encode_packet: Start, SA = { 0xaf86e0cf 729d125b - a8029a79 ce4d1318 } / 00000000, nego = -1 May 31 10:46:54 ike_send_packet: Start, send SA = { af86e0cf 729d125b - a8029a79 ce4d1318}, nego = -1, src=n.n.135.252:500, dst = n.n.248.242:500, routing table id = 0 May 31 10:46:54 ike_get_sa: Start, SA = { af86e0cf 729d125b - a8029a79 ce4d1318 } / 00000000, remote = n.n.248.242:500 May 31 10:46:54 ike_sa_find: Found SA = { af86e0cf 729d125b - a8029a79 ce4d1318 } May 31 10:46:54 ike_decode_packet: Start May 31 10:46:54 ike_decode_packet: Start, SA = { af86e0cf 729d125b - a8029a79 ce4d1318} / 00000000, nego = -1 May 31 10:46:54 ike_st_i_nonce: Start, nonce[0..16] = d2959985 f7bd4d59 ... May 31 10:46:54 ike_st_i_ke: Ke[0..128] = 1ea5215a 5c0af9e0 ... May 31 10:46:54 ike_st_i_cr: Start May 31 10:46:54 ike_st_i_cert: Start May 31 10:46:54 ike_st_i_private: Start May 31 10:46:54 ike_st_o_ke: Start May 31 10:46:54 ike_st_o_nonce: Start May 31 10:46:54 ike_policy_reply_isakmp_nonce_data_len: Start

 

 

 

 

 

Distinguished Expert
MMcD
Posts: 628
Registered: ‎07-20-2010
0

Re: openswan to srx220h IPSEC tunnel problem

I see what you mean.  It is weird, I am however inclined to think that this number may not matter and more so what is included in this payload.

 

There is one SA payload and two pairs of proposal and transform payloads in the initiator packet, including SA Payload, Proposal Payload and Transform Payload.

 

I do agree it is odd, have you tried a different method of packet capture?

 

What is the error now when you made the change on the other side?  are you still getting the unrecognized peer error?

MMcD [JNCIP-SEC, JNCIS-ENT, CCNA, MCP]
____________________________________________________

[Please Mark My Solution Accepted if it Helped, Kudos are Appreciated Too]
Contributor
bobjunga
Posts: 63
Registered: ‎02-29-2012
0

Re: openswan to srx220h IPSEC tunnel problem

[ Edited ]

I think both the 'good' and the 'bad' initiator packets contain only one proposal.

* one "Security Association" payload

*      one "Proposal" Payload
*             one "Transform" Payload.

 

What are you getting at with a different method of packet capture? I don't think it is likeley that wireshark is messing up the data. Do you?

 

I am consistently getting the same error u"unrecognized peer" in the SRX log.

 

I originally started out with a lot more Vendor ID payloads at the end of the swan (bad) packet. I was able to find openswan config options to turn off most of them. The two that are left can not be turned off. The first just identifies the IPSEC stack (openswan) and the second announces that swan is willing to perform dead peer detection. The swan developers say that the RFC says it should always send that packet since it is able to perform DPD and that the other side will ignore it if it wants.

 

Since I could not stop swan from advertising DPD, I also tried turning on DPD on the SRX and that made no difference.

 

I am going to try to add another proposal to the swan config so that the proposal I wnat to match will become 1 instead of 0 to see if that makes a difference.

 

--BobG

Avature

Contributor
bobjunga
Posts: 63
Registered: ‎02-29-2012
0

Re: openswan to srx220h IPSEC tunnel problem

I could not figure out how to add a second proposal but I did add a second transform inside the single proposal payload. The only attribute in the proposal besides the transform objects are the "Protocol ID : ISAKMP" and "SPI Size: 0" fields. I do not see how to specify those in the openswan config.

 

Now the correct transorm set is at index 1 but it did not make a difference.

 

--BobG

Avature

Contributor
bobjunga
Posts: 63
Registered: ‎02-29-2012
0

Re: openswan to srx220h IPSEC tunnel problem

SOLVED!

 

Yesterday JTAC connected to my computer and fixed my problem.

 

It turned out that the problem was that I had configured the second vpn to use tunnel interface st1.0.   She changed it to add a second unit to st0 and made the vpn use st0.1. The first site-to-site vpn (which always worked) uses st0.0 and now the second one (swan) uses st0.1. It let me configure a st1 interface so I don't know if there is ever a case when st1 would be correct.

 

I still don't understand why the tunnel interface matters to IKE gateway negotiation. After all, couldn't I have more than one vpn tunnel using that IKE gateway? Why wouldn't the IKE SA establish independantly from the vpn tunnel that uses it?

 

My JTAC tech was not very talkitive so I was not able to find out.

 

BTW, before the JTAC called, I upgraded my SRX to 11.4.  The problem remained with 11.4 but the log messages changed significantly. With 11.4, it tries to use IKEv2 first, and then falls back to trying IKEv1. IKEv1 failed, but instead of saying that no gateway could be found, it found my Remote access dynamic gateway and then decided that the policy did not match that gateway.

 

--BobG

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.