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
_______________________________________________
Swan-dev mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan-dev
