[Swan] 3.1 rpm package

[Philippe Vouters]

Nick,

What about NOT commenting out ike= and phase2alg= ????

Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

Le 16/03/2013 14:48, Nick Howitt a écrit :
> OK,
>
> From "ipsec auto --status | grep -i aes | grep -i mum":
>
> 000 "MumIn"[2]:   IKE algorithms wanted: 
> AES_CBC(7)_256-SHA1(2)_000-MODP2048(14); flags=-strict
> 000 "MumIn"[2]:   IKE algorithms found: 
> AES_CBC(7)_256-SHA1(2)_160-MODP2048(14)
> 000 "MumIn"[2]:   IKE algorithm newest: AES_CBC_256-SHA1-MODP2048
> 000 "MumIn"[2]:   ESP algorithms wanted: AES(12)_256-MD5(1)_000, 
> AES(12)_256-SHA1(2)_000; flags=-strict
> 000 "MumIn"[2]:   ESP algorithms loaded: AES(12)_256-MD5(1)_128, 
> AES(12)_256-SHA1(2)_160
> 000 "MumIn"[2]:   ESP algorithm newest: AES_256-HMAC_SHA1; 
> pfsgroup=<Phase1>
>
> This is OK in Openswan which does not have strict matching (actually 
> it appears to allow anything even 3DES when you specify AES). Is 
> Libreswan no longer the same? How would I specify ike and phase2alg to 
> match?
>
> I also thought only specifying phase2alg=aes256, it should allow 
> aes256 with MD5 or SHA1 and with any MODP
>
> Regards,
>
> Nick
>
> On 16/03/2013 13:34, Philippe Vouters wrote:
>> Nick,
>> One possible cause is a mismatch of the ike/phase2alg with the remote 
>> peer. Up to you to see whether this applies.
>>  ike=aes256-sha1;modp2048
>>  phase2alg=aes256
>> Philippe Vouters (Fontainebleau/France)
>> URL:http://vouters.dyndns.org/
>> SIP:sip:Vouters at sip.linphone.org
>> Le 16/03/2013 12:52, Nick Howitt a écrit :
>>> It is there in https://download.libreswan.org/binaries/rhel/ but I 
>>> can't get it to work :(
>>>
>>> I have installed it and with identical configs to openswan all I get 
>>> in my logs is:
>>> Mar 16 11:43:59 server pluto[10870]: packet from 88.104.26.203:500: 
>>> received Vendor ID payload [Dead Peer Detection]
>>> Mar 16 11:43:59 server pluto[10870]: packet from 88.104.26.203:500: 
>>> received Vendor ID payload [RFC 3947]
>>> Mar 16 11:43:59 server pluto[10870]: packet from 88.104.26.203:500: 
>>> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
>>> Mar 16 11:43:59 server pluto[10870]: packet from 88.104.26.203:500: 
>>> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
>>> Mar 16 11:43:59 server pluto[10870]: packet from 88.104.26.203:500: 
>>> ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
>>> Mar 16 11:43:59 server pluto[10870]: packet from 88.104.26.203:500: 
>>> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
>>> Mar 16 11:43:59 server pluto[10870]: packet from 88.104.26.203:500: 
>>> initial Main Mode message received on 82.19.147.85:500 but no 
>>> connection has been authorized with policy=PSK
>>>
>>> My Ipsec.conf is:
>>> # The config file changed quite a bit from 1.x.
>>> # See 
>>> http://www.freeswan.org/freeswan_trees/freeswan-2.00/doc/upgrading.html
>>>
>>> version 2.0
>>>
>>> # Default policy
>>> #---------------
>>>
>>> config setup
>>>     interfaces=%defaultroute
>>>     plutodebug=none    # plutodebug="all crypt"
>>>     # plutodebug=controlmore
>>>     klipsdebug=none
>>>     oe=no
>>>     protostack=netkey    # 2.6.x only
>>> virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!192.168.2.0/24,%v4:!192.168.3.0/24
>>>     nat_traversal=yes
>>>
>>>
>>> conn %default
>>>     type=tunnel
>>>     authby=secret
>>>
>>> # Tunnels defined in separate files
>>> #----------------------------------
>>>
>>> include /etc/ipsec.d/ipsec.*.conf
>>>
>>>
>>> One of the sub files, /etc/ipsec.d/ipsec.unmanaged.MumIn.conf, is:
>>> conn MumIn
>>>  type=tunnel
>>>  authby=secret
>>>  dpdtimeout=120
>>>  dpddelay=30
>>>  auto=add
>>>  left=%defaultroute
>>>  leftsourceip=192.168.2.1
>>>  leftsubnet=192.168.2.0/24
>>>  leftid=@Nick
>>>  right=%any
>>>  rightsubnet=192.168.10.0/24
>>>  salifetime=24h
>>>  dpdaction=clear
>>>  ikelifetime=24h
>>>  ike=aes256-sha1;modp2048
>>>  phase2alg=aes256
>>>  rekey=no
>>>
>>> The secrets file contains:
>>> @Nick %any : PSK "PSK_Here"
>>>
>>> This happens for both my remote locations. One is behind NAT, the 
>>> other is not.
>>>
>>> Regards,
>>>
>>> Nick
>>>
>>> On 16/03/2013 11:42, T.J. Yang wrote:
>>>> Hi Paul,
>>>>
>>>> Is there outstanding/roadblock  issue ?
>>>> Hoping you can release libreswan 3.1 CentOS/RHEL 6 package to repo 
>>>> soon.
>>>>
>>>>
>>>> Thanks
>>>>
>>>> tj
>>>>
>>>> -- 
>>>> T.J. Yang
>>>>
>>>>
>>>> _______________________________________________
>>>> Swan mailing list
>>>> Swan at lists.libreswan.org
>>>> https://lists.libreswan.org/mailman/listinfo/swan
>>>
>>>
>>>
>>> _______________________________________________
>>> Swan mailing list
>>> Swan at lists.libreswan.org
>>> https://lists.libreswan.org/mailman/listinfo/swan
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20130316/03267467/attachment.html>