> > This was the case up until the last change (see above) - which I can
> > roll back right away - but that did not work for me. I ended up with the
> > public IP as source address in the xfrm policy installed by libreswan
> > anyway. What I can further try is to use rightsubnet instead of
> > rightaddresspool.
>
> I do not understand how that could happen.
OK. Before sending you lenthy logfiles, I've tried to experiment a
bit more. I hope the results might be a lead. The roadwarrior/initiator was
configured with
conn mysrv
left=%defaultroute
leftcert=roadwarrior
leftid=%fromcert
leftrsasigkey=%cert
right=srv.pp.uu.bb
rightid=%fromcert
rightrsasigkey=%cert
leftsubnet=0.0.0.0/0
rightsubnet=srv.ii.nn.tt/32
narrowing=yes
ikev2=insist
auto=start
authby=rsasig
pfs=yes
aggressive=no
salifetime=1h
negotiationshunt=hold
failureshunt=drop
rightca=%same
... and I did not change anything in this config throughout any of the
experiments described in this message.
The configuration of the server/responder started with the last (i. e.
non-working) configuration:
conn roadwarrior
left=%defaultroute
leftcert=myserver
leftid=%fromcert
leftrsasigkey=%cert
right=%any
rightid="C=ZZ,O=Privlan,CN=roadwarrior.privlan"
rightrsasigkey=%cert
leftsubnet=srv.ii.nn.tt/32
rightaddresspool=192.0.2.0/24
narrowing=yes
auto=add
ikev2=yes
authby=rsasig
pfs=yes
aggressive=no
salifetime=1h
negotiationshunt=hold
failureshunt=drop
rekey=no
As mentioned before, this configuration results in an established
(authenticated) tunnel, but wrong xfrm policies, at least on the roadwarrior
end (with rw.pp.uu.bb as source IP instead of rw.ii.nn.tt).
After replacing rightaddresspool=192.0.2.0/24 on the server/responder with
rightsubnet=vhost:%priv,%no, the tunnel is not established at all due to
pluto[3291]: "mysrv"[1] srv.pp.uu.bb #1: initiator established IKE SA;
authenticated peer '8192-bit RSASSA-PSS with SHA2_512' digital signature using
peer certificate 'C=ZZ, O=Privlan, CN=server.privlan' issued by CA 'CN=Privlan
CA'
pluto[3291]: | delref pkp@NULL (authsig_and_log_using_pubkey() +411
/programs/pluto/keys.c)
pluto[3291]: | parent state #1: PARENT_I2(open IKE SA) =>
ESTABLISHED_IKE_SA(established IKE SA)
pluto[3291]: | pstats #1 ikev2.ike established
pluto[3291]: | redirect: no redirect payload in IKE_AUTH reply
pluto[3291]: | FOR_EACH_STATE_... in (nat_traversal_ka_event() +302
/programs/pluto/nat_traversal.c)
pluto[3291]: | found "mysrv"[1] srv.pp.uu.bb #2
pluto[3291]: | skipping NAT-T KEEP-ALIVE: #2 is not an established IKE SA
pluto[3291]: | found "mysrv"[1] srv.pp.uu.bb #1
pluto[3291]: | skipping NAT-T KEEP-ALIVE: recent message sent using the IKE SA
on conn mysrv
pluto[3291]: | matches: 2
pluto[3291]: "mysrv"[1] srv.pp.uu.bb #2: IKE_AUTH response rejected Child SA
with TS_UNACCEPTABLE
(logfile from the roadwarrior/initiator).
I also tried to add
virtual-private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:!srv.ii.nn.0/24,
but this change had no impact that I would be aware of.
However, after having changed the above to rightsubnet=rw.ii.nn.tt/32, the
tunnel got established and the xfrm policies on the roadwarrior/initiator
got installed correctly (i. e. with rw.ii.nn.tt as source IP), too. In other
words, everything worked, including tunnel traffic counters incrementing,
etc.
I have observed the same behaviour also when expanding the rightsubnet to
rw.ii.nn.0/24.
So, at this point, I need to know how to achieve this without prior
knowledge of the internal IP assigned to the roadwarrior (which is the
standard scenario). Plus, it would be nice to know why this happens at all.
> > And do I need to put a static leftsubnet= on the roadwarrior, identical to
> > the rightsubnet= on the server?
>
> Yes but isnt this the same question as above? because roadwarrior ==
> initiator ?
Yes, but what I had on my mind here was whether it is enough to have
rightsubnet=so.me.ip on the server (and that so.me.ip "propagates somehow"
to the roadwarrior during negotiation) or I need to allways include a
corresponding leftsubnet=so.me.ip on the roadwarrior. Plus, additionally,
whether I need to set up a virtual interface on the roadwarrior with
so.me.ip. I was asking this because I saw some old configs from *swan which
seemed to suggest that, at least in the past, these things needed to be done
manually.
> Note if you want to ask further help, you will need to send logs and
> config and not censor any IP addresses to make it possible for us to
> really see what is happening.
No problem with that (should the above not help). In that case,
however, I would prefer to send the verbatim logs/dumps directly to you.
Just please mail me what do you think is necessary.
Many thanks,
Phil
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
