[Swan] IKEv1 XAUTH with Mac OS (pluto crash)

[Paul Wouters]

On Wed, 23 Sep 2015, Sven Schiwek wrote:

>        virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,!192.168.10.0/24

that should be:

         virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,v4:!192.168.10.0/24

> conn xauth-aggr

>        aggrmode=no

Note that is a little misleading in the name.

> This connection is working fine, as long I don’t set the a “Group Name” in the Mac OS VPN configuration.
> As soon I set the “Group Name” in Mac OS I also have to set aggrmode=yes because of:
>
> "initial Aggressive Mode message from 192.168.10.129 but no (wildcard) connection has been configured with policy PSK+XAUTH+AGGRESSIVE+IKEV1_ALLOW"

Seems that once you set the groupname it switches from Main Mode to
Aggressive Mode. So that is right to change then.

> Sep 23 13:44:15 pm-kvm01 pluto[11122]: "xauth-aggr"[1] 192.168.10.129 #1: Aggressive mode peer ID is ID_KEY_ID: '@#0x7376656e7578'
> Sep 23 13:44:15 pm-kvm01 pluto[11122]: "xauth-aggr"[1] 192.168.10.129 #1: switched from "xauth-aggr"[1] 192.168.10.129 to "xauth-aggr"
> Sep 23 13:44:15 pm-kvm01 pluto[11122]: "xauth-aggr"[2] 192.168.10.129 #1: deleting connection "xauth-aggr" instance with peer 192.168.10.129 {isakmp=#0/ipsec=#0}
> Sep 23 13:44:15 pm-kvm01 pluto[11122]: "xauth-aggr"[2] 192.168.10.129 #1: responding to Aggressive Mode, state #1, connection "xauth-aggr" from 192.168.10.129
> Sep 23 13:44:15 pm-kvm01 pluto[11122]: "xauth-aggr"[2] 192.168.10.129 #1: enabling possible NAT-traversal with method RFC 3947 (NAT-Traversal)
> Sep 23 13:44:15 pm-kvm01 pluto[11122]: "xauth-aggr"[2] 192.168.10.129 #1: transition from state STATE_AGGR_R0 to state STATE_AGGR_R1
> Sep 23 13:44:15 pm-kvm01 pluto[11122]: "xauth-aggr"[2] 192.168.10.129 #1: STATE_AGGR_R1: sent AR1, expecting AI2
> Sep 23 13:44:15 pm-kvm01 pluto[11122]: packet from <invalid>:50695: ASSERTION FAILED at /home/sysop/libreswan-3.15/programs/pluto/ikev1_aggr.c:207: dh->pcrc_md != NULL
> Sep 23 13:44:15 pm-kvm01 systemd[1]: ipsec.service: Main process exited, code=killed, status=6/ABRT

It seems we switched state but we already commited to some crypto, and
so we shouldn't switch anymore. The new state seems incomplete as it
is missing a valid IP address of the incoming packet and missing some
crypto state on which it is passerting.

> Is there anything I forgot to set up or is there something wrong with my ipsec configuration?

Well, we should not crash. That's our problem. A problem in your
configuration I see is that you are using authby=secret and
uniqueids=yes, but with group psk you have no unique ids so each
connection will use the same ID so you must set uniqueids=no.

Paul