[Swan] No proposal chosen in version 3.21
Dynastic Space
dynasticspace at gmail.com
Fri Sep 15 20:52:03 UTC 2017
Thanks for your assistance. We are very novice in this, and any help is
great.
Note that we are running a vpn server for iphone users, so we do not really
have much control over what protocol they use.
This is how I set the configuration file:
# libreswan /etc/ipsec.conf configuration file
config setup
protostack=netkey
# exclude networks used on server side by adding %v4:!a.b.c.0/24
virtual_private=%v4:
10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8,%v4:!10.231.247.0/24,%v4:!10.231.246.0/24
# PSK clients can have the same ID if they send it based on IP address.
uniqueids=no
plutostderrlog=/var/log/libreswan
conn xauth-psk
authby=secret
pfs=no
auto=add
rekey=no
left=%defaultroute
leftsubnet=0.0.0.0/0
rightaddresspool=10.231.247.10-10.231.247.254
right=%any
# make cisco clients happy
cisco-unity=yes
# address of your internal DNS server
modecfgdns1=172.31.14.50
leftxauthserver=yes
rightxauthclient=yes
leftmodecfgserver=yes
rightmodecfgclient=yes
modecfgpull=yes
xauthby=file
# xauthby=alwaysok MUST NOT be used with PSK
# Can be played with below
#dpddelay=30
#dpdtimeout=120
#dpdaction=clear
# xauthfail=soft
ike-frag=yes
ikev2=never
ike=aes128-sha2_256;modp2048
esp=aes128-sha2_256;modp2048
And still - this is the result:
20:33:40.054888 IP (tos 0x20, ttl 43, id 2204, offset 0, flags [none],
proto UDP (17), length 876)
77.127.99.61.53217 > 172.31.14.50.500: [udp sum ok] isakmp 1.0 msgid
00000000 cookie 371f2a168537a939->0000000000000000: phase 1 I ident:
(sa: doi=ipsec situation=identity
(p: #1 protoid=isakmp transform=15
(t: #1 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=sha2-256)(type=group desc value=modp2048))
(t: #2 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=sha1)(type=group desc value=modp2048))
(t: #3 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=md5)(type=group desc value=modp2048))
(t: #4 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=sha2-512)(type=group desc value=modp2048))
(t: #5 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=sha2-256)(type=group desc value=modp1536))
(t: #6 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=sha1)(type=group desc value=modp1536))
(t: #7 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=md5)(type=group desc value=modp1536))
(t: #8 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=sha1)(type=group desc value=modp1024))
(t: #9 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0100)(type=auth
value=fde9)(type=hash value=md5)(type=group desc value=modp1024))
(t: #10 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0080)(type=auth
value=fde9)(type=hash value=sha1)(type=group desc value=modp1024))
(t: #11 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=aes)(type=keylen value=0080)(type=auth
value=fde9)(type=hash value=md5)(type=group desc value=modp1024))
(t: #12 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=3des)(type=auth value=fde9)(type=hash
value=sha1)(type=group desc value=modp1024))
(t: #13 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=3des)(type=auth value=fde9)(type=hash
value=md5)(type=group desc value=modp1024))
(t: #14 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=1des)(type=auth value=fde9)(type=hash
value=sha1)(type=group desc value=modp1024))
(t: #15 id=ike (type=lifetype value=sec)(type=lifeduration
value=0e10)(type=enc value=1des)(type=auth value=fde9)(type=hash
value=md5)(type=group desc value=modp1024))))
(vid: len=16 4a131c81070358455c5728f20e95452f)
(vid: len=16 4df37928e9fc4fd1b3262170d515c662)
(vid: len=16 8f8d83826d246b6fc7a8a6a428c11de8)
(vid: len=16 439b59f8ba676c4c7737ae22eab8f582)
(vid: len=16 4d1e0e136deafa34c4f3ea9f02ec7285)
(vid: len=16 80d0bb3def54565ee84645d4c85ce3ee)
(vid: len=16 9909b64eed937c6573de52ace952fa6b)
(vid: len=16 7d9419a65310ca6f2c179d9215529d56)
(vid: len=16 cd60464335df21f87cfdb2fc68b6a448)
(vid: len=16 90cb80913ebb696e086381b5ec427b1f)
(vid: len=8 09002689dfd6b712)
(vid: len=16 12f5f28c457168a9702d9fe274cc0100)
(vid: len=20 4048b7d56ebce88525e7de7f00d6c2d380000000)
(vid: len=16 afcad71368a1f1c96b8696fc77570100)
20:33:40.055372 IP (tos 0x0, ttl 64, id 50803, offset 0, flags [DF], proto
UDP (17), length 68)
172.31.14.50.500 > 77.127.99.61.53217: [bad udp cksum 0x6b4f ->
0xd990!] isakmp 1.0 msgid 00000000 cookie
371f2a168537a939->951eb0f332f2cf1b: phase 1 R inf:
(n: doi=ipsec proto=isakmp type=NO-PROPOSAL-CHOSEN)
Thanks,
Dynastic
On Fri, Sep 15, 2017 at 4:55 PM, Paul Wouters <paul at nohats.ca> wrote:
> On Fri, 15 Sep 2017, Dynastic Space wrote:
>
> In version 3.19 we used the following configuration:
>>
>
> conn xauth-psk
>>
>
> [no ike= or esp=/phase2= lines]
>
> I just upgraded to version 3.21, using this same configuration. the client
>> is sending the following proposal:
>>
>
> 3.21 has been updated to reflect RFC-8247
>
> https://tools.ietf.org/html/rfc8247
>
> Even though it technically does not cover IKEv1 - only IKEv2 - we have
> also bumped some requirements in IKEv1. Most notably, since all IKEv1
> stacks support both modp1536 (DH5) and modp1024 (DH2), and the latter
> is pretty weak, we have kicked that one out of our default proposal
> list. Additional, the ESP RFC (7321bis) will be published in a few days
> as RFC-8221 and 3.21 also tries to comply there. This means mostly that
> MD5 is kicked out of the default proposal set.
>
> So with that in mind:
>
> (sa: doi=ipsec situation=identity
>> (p: #1 protoid=isakmp transform=15
>> (t: #1 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=sha2-256)(type=group
>> desc value=modp2048))
>>
>
> This is ike=aes128-sha2_256;modp2048 and should be accepted by us?
> Possibly we had not added modp2048 to the default group?
>
>
> (t: #2 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=sha1)(type=group desc
>> value=modp2048))
>>
>
> ike=aes128-sha1;modp2048 Same
>
> (t: #3 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=md5)(type=group desc
>> value=modp2048))
>>
>
> ike=aes128-md5;modp2048 md5, so rejected.
>
> (t: #4 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=sha2-512)(type=group
>> desc value=modp2048))
>>
>
> ike=aes128-sha2_512;modp1536 Should also be accepted?
>
> (t: #5 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=sha2-256)(type=group
>> desc value=modp1536))
>>
>
> ike=aes128-sha2_256;modp1536 Should also be accepted?
>
> (t: #6 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=sha1)(type=group desc
>> value=modp1536))
>>
>
> ike=aes128-sha1;modp1536 should also be accepted.
>
> (t: #7 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=md5)(type=group desc
>> value=modp1536))
>>
>
> ike=aes128-md5;modp1536 rejected for md5
>
> (t: #8 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=sha1)(type=group desc
>> value=modp1024))
>> (t: #9 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0100)(type=auth value=fde9)(type=hash value=md5)(type=group desc
>> value=modp1024))
>> (t: #10 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0080)(type=auth value=fde9)(type=hash value=sha1)(type=group desc
>> value=modp1024))
>> (t: #11 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=aes)(type=keylen
>> value=0080)(type=auth value=fde9)(type=hash value=md5)(type=group desc
>> value=modp1024))
>> (t: #12 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=3des)(type=auth
>> value=fde9)(type=hash value=sha1)(type=group desc value=modp1024))
>> (t: #13 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=3des)(type=auth
>> value=fde9)(type=hash value=md5)(type=group desc value=modp1024))
>> (t: #14 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=1des)(type=auth
>> value=fde9)(type=hash value=sha1)(type=group desc value=modp1024))
>> (t: #15 id=ike (type=lifetype value=sec)(type=lifeduration
>> value=0e10)(type=enc value=1des)(type=auth
>> value=fde9)(type=hash value=md5)(type=group desc value=modp1024))))
>>
>
> All of these rejected because of modp1024 (DH2)
>
> but the server is responding with
>> (n: doi=ipsec proto=isakmp type=NO-PROPOSAL-CHOSEN)
>>
>
> I'm not sure why you are seeing that. Can you try adding:
>
> ike=aes128-sha2_256;modp2048
> ike=aes128-sha2_256;modp2048
>
> Do you have all the same kind of clients? If not, you might need to make
> a more complicated proposal with multiple entries.
>
> Note that you might run into similar things for esp=/phase2alg= once
> you fixup this stage.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20170915/fde96542/attachment-0001.html>
More information about the Swan
mailing list