[Openswan Users] Openswan 2.6.24 => Juniper SRX

[Scott T. Cameron]

It was not, but I've gone and put it in and restarted ipsec now, with no
noticeable change in behaviour.

Here's my config for reference sake:

config setup
        plutodebug=none
        protostack=netkey
        plutowait=yes
        nat_traversal=no
        nhelpers=0
        oe=off

conn idc
        auto=start
        pfs=no
        authby=secret
        ikev2=no
        ike=aes128-sha1
        phase2alg=aes128-sha1
        salifetime=8h
        ikelifetime=1h
        type=tunnel
        rekey=yes

        left=89.202.x.x
        leftsourceip=192.168.90.200
        leftsubnet=192.168.90.0/24
        right=74.115.x.x
        rightsubnet=172.30.0.0/16

On Fri, Feb 4, 2011 at 3:07 PM, Paul Wouters <paul at xelerance.com> wrote:

> On Fri, 4 Feb 2011, Scott T. Cameron wrote:
>
> Are you missing oe=off in ipsec.conf's "config setup" section?
>
> Paul
>
>  Date: Fri, 4 Feb 2011 14:23:19 -0500
>> From: Scott T. Cameron <routehero at gmail.com>
>> To: users at openswan.org
>> Subject: Re: [Openswan Users] Openswan 2.6.24 => Juniper SRX
>>
>>
>> I took time to upgrade today.
>>
>> meta:~# ipsec --version
>> Linux Openswan U2.6.32/K2.6.24-sn (netkey)
>> See `ipsec --copyright' for copyright information.
>>
>> ipsec auto --status snip:
>>
>> 000 "idc": 192.168.90.0/24===89.202.x.x
>> <89.202.x.x>[+S=C]...74.115.x.x<74.115.x.x>[+S=C]===172.30.0.0/16;
>> erouted HOLD; eroute
>> owner: #0
>> 000 "idc":     myip=192.168.90.200; hisip=unset;
>> 000 "idc":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s;
>> rekey_fuzz: 100%; keyingtries: 0
>> 000 "idc":   policy: PSK+ENCRYPT+TUNNEL+UP+SAREFTRACK+lKOD+rKOD; prio:
>> 24,16; interface: eth0;
>> 000 "idc":   newest ISAKMP SA: #1; newest IPsec SA: #0;
>> 000
>> 000 #37: "idc":500 STATE_QUICK_I1 (sent QI1, expecting QR1);
>> EVENT_RETRANSMIT in 14s; lastdpd=-1s(seq in:0 out:0); idle;
>> import:admin initiate
>> 000 #36: "idc":500 STATE_QUICK_I1 (sent QI1, expecting QR1);
>> EVENT_RETRANSMIT in 14s; lastdpd=-1s(seq in:0 out:0); idle;
>> import:admin initiate
>> 000 #35: "idc":500 STATE_QUICK_I1 (sent QI1, expecting QR1);
>> EVENT_RETRANSMIT in 14s; lastdpd=-1s(seq in:0 out:0); idle;
>> import:admin initiate
>> 000 #34: "idc":500 STATE_QUICK_I1 (sent QI1, expecting QR1);
>> EVENT_RETRANSMIT in 14s; lastdpd=-1s(seq in:0 out:0); idle;
>> import:admin initiate
>> [snip]
>> 000 #1: "idc":500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE
>> in 2503s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0);
>> idle; import:admin initiate
>>
>>
>> syslog snip:
>> Feb  4 20:20:53 meta pluto[29438]: initiate on demand from
>> 192.168.90.11:45819 to 172.30.77.45:514 proto=6 state: fos_start
>> because: acquire
>> Feb  4 20:20:53 meta pluto[29438]: "idc" #550: initiating Quick Mode
>> PSK+ENCRYPT+TUNNEL+UP+SAREFTRACK {using isakmp#1
>> msgid:02b0b8d6 proposal=AES(12)_128-SHA1(2)_160 pfsgroup=no-pfs}
>>
>>
>> Seems to be the same issue, in general.  First IPSEC tunnel goes up, but
>> it stays in hold state and the rest of the boxes
>> (mostly syslog) cause it to try to bring up a zillion new tunnels.
>> Any other pointers?
>>
>> Scott
>>
>> On Fri, Jan 28, 2011 at 2:19 PM, Paul Wouters <paul at xelerance.com> wrote:
>>      On Fri, 28 Jan 2011, Scott T. Cameron wrote:
>>
>>            Subject: [Openswan Users] Openswan 2.6.24 => Juniper SRX
>>
>>
>>
>>            Jan 28 19:53:24  pluto[16783]: initiate on demand from
>> 192.168.90.63:35718 to
>>
>>
>>      The config is fairly basic.  The initiate on demands won't stop -- it
>> goes in to the
>>      thousands of range.
>>
>>
>> v2.6.29 (September 27, 2010)
>>
>> * NETKEY: Fix for spurious %hold netlink-acquires [Paul/dhr]
>>
>> Paul
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openswan.org/pipermail/users/attachments/20110204/b85640a5/attachment-0001.html