Discussion:
[Swan] PSK+AGGRESSIVE+IKEV1_ALLOW
Chuck Wolber
2015-06-09 02:50:32 UTC
Permalink
I am running Libreswan 3.14rc1 on CentOS 7.1.1503 with all updates applied.
This environment is only being used as a dev/test/proof-of-concept
environment, and is not being exposed to the Internet. SELinux and iptables
have been turned off.

My goal is to start using the Apple provided Personal VPN API to
programmatically control the VPN from within an application running on iOS
8.3. It should be noted that this is a different VPN client than the built
in Cisco VPN IPSEC client. For Xcode developers, this is part of the
NetworkExtension bundle.

I am able to connect to the VPN server with a variety of methods, but when
I attempt to connect from within my application with the Personal VPN API,
I get the following message on the server side:

initial Aggressive Mode message from 10.1.0.4 but no (wildcard) connection
has been configured with policy PSK+AGGRESSIVE+IKEV1_ALLOW


This is my server side configuration:

conn RoadWarriors-ikev1-aggr-psk
authby=secret
aggrmode=yes
auto=add
rekey=no
pfs=no
left=10.1.0.1
leftid=@10.1.0.1
leftsubnet=0.0.0.0/0
rightaddresspool=10.1.0.10-10.1.0.254
right=%any
modecfgdns1=10.1.0.1
leftxauthserver=yes
rightxauthclient=yes
leftmodecfgserver=yes
rightmodecfgclient=yes
modecfgpull=yes
xauthby=alwaysok
dpddelay=30
dpdtimeout=120
dpdaction=clear
ike-frag=yes
ikev2=never



When I check ipsec status, it seems like the policy should handle this:

000 "RoadWarriors-ikev1-aggr-psk": policy:
PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW;
For reference, the full set of connection logs are:

Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: received
Vendor ID payload [FRAGMENTATION 80000000]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: received
Vendor ID payload [RFC 3947]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-08]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-07]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-06]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-05]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-04]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: ignoring
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: received
Vendor ID payload [Dead Peer Detection]
Jun 9 02:41:43 vpnserver pluto[4733]: packet from 10.1.0.4:500: initial
Aggressive Mode message from 10.1.0.4 but no (wildcard) connection has been
configured with policy PSK+AGGRESSIVE+IKEV1_ALLOW


Google does not seem to have any answers, nor does the man page for
ipsec.conf. A look in the source code does not turn up anything obvious
either. Is there something I am missing in the configuration?

..Ch:W..
Paul Wouters
2015-06-09 03:55:45 UTC
Permalink
My goal is to start using the Apple provided Personal VPN API to programmatically control the VPN from within an application running on
iOS 8.3. It should be noted that this is a different VPN client than the built in Cisco VPN IPSEC client. For Xcode developers, this is
part of the NetworkExtension bundle.
I'm not sure what this means in practise....
I am able to connect to the VPN server with a variety of methods, but when I attempt to connect from within my application with the
initial Aggressive Mode message from 10.1.0.4 but no (wildcard) connection has been configured with policy
PSK+AGGRESSIVE+IKEV1_ALLOW
PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW;
Note that the error message is a little misleading. While it does check
some policy bits for the display, it does not tell you everything, so
even if another important policy bit does not match, you will get the
misleading "with policy PSK+AGGRESSIVE+IKEV1_ALLOW".

For instance, this could be a pfs=yes/no mismatch. Or a subnet mismatch
or ID mismatch.
conn RoadWarriors-ikev1-aggr-psk
        authby=secret
        aggrmode=yes
        auto=add
        rekey=no
        pfs=no  
        left=10.1.0.1
        leftsubnet=0.0.0.0/0
        rightaddresspool=10.1.0.10-10.1.0.254
        right=%any
        modecfgdns1=10.1.0.1
        leftxauthserver=yes
        rightxauthclient=yes
        leftmodecfgserver=yes
        rightmodecfgclient=yes
        modecfgpull=yes
        xauthby=alwaysok
        dpddelay=30
        dpdtimeout=120
        dpdaction=clear
        ike-frag=yes
        ikev2=never
It would help to see the matching plutodebug=all log so we can compare
what you receive with what you configured.

Paul
Chuck Wolber
2015-06-09 18:31:00 UTC
Permalink
Post by Paul Wouters
Post by Chuck Wolber
I am able to connect to the VPN server with a variety of methods, but
when I attempt to connect from within my application with the
initial Aggressive Mode message from 10.1.0.4 but no (wildcard)
connection has been configured with policy
PSK+AGGRESSIVE+IKEV1_ALLOW
PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW;
Note that the error message is a little misleading. While it does check
some policy bits for the display, it does not tell you everything, so
even if another important policy bit does not match, you will get the
misleading "with policy PSK+AGGRESSIVE+IKEV1_ALLOW".
For instance, this could be a pfs=yes/no mismatch. Or a subnet mismatch
or ID mismatch.
conn RoadWarriors-ikev1-aggr-psk
Post by Chuck Wolber
authby=secret
aggrmode=yes
auto=add
rekey=no
pfs=no
left=10.1.0.1
leftsubnet=0.0.0.0/0
rightaddresspool=10.1.0.10-10.1.0.254
right=%any
modecfgdns1=10.1.0.1
leftxauthserver=yes
rightxauthclient=yes
leftmodecfgserver=yes
rightmodecfgclient=yes
modecfgpull=yes
xauthby=alwaysok
dpddelay=30
dpdtimeout=120
dpdaction=clear
ike-frag=yes
ikev2=never
It would help to see the matching plutodebug=all log so we can compare
what you receive with what you configured.
I have attached the log file with plutodebug=all added to the setup
section. The log includes the IPSec daemon startup sequence. You can jump
directly to time index 18:13:01 for the connection attempt.

..Ch:W..
Paul Wouters
2015-06-09 19:02:19 UTC
Permalink
Post by Chuck Wolber
PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW;
Jun 9 18:13:01 vpnserver pluto[6728]: | found policy =
PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
(RoadWarriors-ikev1-aggr-psk)

Jun 9 18:13:01 vpnserver pluto[6728]: | find_next_host_connection returns empty
Jun 9 18:13:01 vpnserver pluto[6728]: packet from 10.1.0.4:500: initial Aggressive Mode message from 10.1.0.4 but no (wildcard) connection has been configured with policy PSK+AGGRESSIVE+IKEV1_ALLOW
Post by Chuck Wolber
      conn RoadWarriors-ikev1-aggr-psk
              authby=secret
              aggrmode=yes
              auto=add
              rekey=no
              pfs=no  
              left=10.1.0.1
              leftsubnet=0.0.0.0/0
              rightaddresspool=10.1.0.10-10.1.0.254
              right=%any
              modecfgdns1=10.1.0.1
              leftxauthserver=yes
              rightxauthclient=yes
              leftmodecfgserver=yes
              rightmodecfgclient=yes
              modecfgpull=yes
              xauthby=alwaysok
              dpddelay=30
              dpdtimeout=120
              dpdaction=clear
              ike-frag=yes
              ikev2=never
So it seems to match up. Odd. Can you show "ipsec status |grep RoadWarriors-ikev1-aggr-psk" ?

Paul
Chuck Wolber
2015-06-09 19:19:05 UTC
Permalink
Post by Paul Wouters
Post by Chuck Wolber
PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW;
Jun 9 18:13:01 vpnserver pluto[6728]: | found policy =
PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW
(RoadWarriors-ikev1-aggr-psk)
Jun 9 18:13:01 vpnserver pluto[6728]: | find_next_host_connection returns empty
Jun 9 18:13:01 vpnserver pluto[6728]: packet from 10.1.0.4:500: initial
Aggressive Mode message from 10.1.0.4 but no (wildcard) connection has been
configured with policy PSK+AGGRESSIVE+IKEV1_ALLOW
conn RoadWarriors-ikev1-aggr-psk
Post by Chuck Wolber
authby=secret
aggrmode=yes
auto=add
rekey=no
pfs=no
left=10.1.0.1
leftsubnet=0.0.0.0/0
rightaddresspool=10.1.0.10-10.1.0.254
right=%any
modecfgdns1=10.1.0.1
leftxauthserver=yes
rightxauthclient=yes
leftmodecfgserver=yes
rightmodecfgclient=yes
modecfgpull=yes
xauthby=alwaysok
dpddelay=30
dpdtimeout=120
dpdaction=clear
ike-frag=yes
ikev2=never
So it seems to match up. Odd. Can you show "ipsec status |grep
RoadWarriors-ikev1-aggr-psk" ?
000 "RoadWarriors-ikev1-aggr-psk":
0.0.0.0/24===10.1.0.1<10.1.0.1>[@10.1.0.1,MS+XS+S=C]...%any[+MC+XC+S=C];
unrouted; eroute owner: #0
000 "RoadWarriors-ikev1-aggr-psk": oriented; my_ip=unset; their_ip=unset
000 "RoadWarriors-ikev1-aggr-psk": xauth info: us:server, them:client,
method:alwaysok; my_xauthuser=[any]; their_xauthuser=[any]
000 "RoadWarriors-ikev1-aggr-psk": modecfg info: us:server, them:client,
modecfg policy:pull, dns1:10.1.0.1, dns2:unset, domain:unset, banner:unset;
000 "RoadWarriors-ikev1-aggr-psk": labeled_ipsec:no;
000 "RoadWarriors-ikev1-aggr-psk": policy_label:unset;
000 "RoadWarriors-ikev1-aggr-psk": ike_life: 3600s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;
000 "RoadWarriors-ikev1-aggr-psk": retransmit-interval: 500ms;
retransmit-timeout: 60s;
000 "RoadWarriors-ikev1-aggr-psk": sha2_truncbug:no; initial_contact:no;
cisco_unity:no; send_vendorid:no;
000 "RoadWarriors-ikev1-aggr-psk": policy:
PSK+ENCRYPT+TUNNEL+DONT_REKEY+XAUTH+MODECFG_PULL+AGGRESSIVE+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW;

000 "RoadWarriors-ikev1-aggr-psk": conn_prio: 24,32; interface: enp0s3;
metric: 0; mtu: unset; sa_prio:auto; nflog-group: unset;
000 "RoadWarriors-ikev1-aggr-psk": dpd: action:clear; delay:30;
timeout:120; nat-t: force_encaps:no; nat_keepalive:yes; ikev1_natt:both
000 "RoadWarriors-ikev1-aggr-psk": newest ISAKMP SA: #0; newest IPsec SA:
#0;


..Ch:W..
Chuck Wolber
2015-06-09 20:30:03 UTC
Permalink
I have managed to make a PSK connection. What I have discovered is that
there is a localIdentifier property in the NEVPNProtocolIPSec object that
really seems to mess with Libreswan 3.14rc1. If I leave it empty, I can get
the PSK connection to complete. The failure modes appear to vary depending
on whether XAUTH (useExtendedAuthentication) is turned on or off, although
I have not traced them down to a solid set of rules just yet.

If this sounds like a potential bug worth resolving in Libreswan, I am
happy to continue working on this with you.

..Ch:W..

Loading...