> > pluto[30425]: "remotesite"[1] 203.0.113.55 #2: responder established Child
> > SA using #1; IPsec tunnel [192.168.1.253-192.168.1.253:0-65535 0] ->
> > [203.0.113.55-203.0.113.55:0-65535 0] {ESPinUDP=>0x7522bc14 <0x80c5c828
> > xfrm=AES_GCM_16_256-NONE NATD=203.0.113.55:4500 DPD=passive}
>
> So responder likes 192.168.1.253/32 <-> 203.0.113.55/32
Makes sense (so I think, at least).
> > On the initiator, the (probably) critical part reads
>
> > pluto[11791]: | evaluating our conn="headq"[1] 198.51.100.33
> > I=0.0.0.0/0:0:0/0 R=192.168.1.253/32:0:0/0 to their:
> > pluto[11791]: | TSi[0] .net=203.0.113.55-203.0.113.55 .iporotoid=0
> > .{start,end}port=0..65535
> > pluto[11791]: | match address end->client=0.0.0.0/0 >=
> > TSi[0]net=203.0.113.55-203.0.113.55: NO
> > pluto[11791]: | reject responder TSi/TSr Traffic Selector
>
> Looks like client is missing narrowing=yes, and now insists on getting
> the whole 0/0 <-> 0/0 instead of allowing the server to narrow it down
> to a single /32 to /32 tunnel.
This shouldn't be the case. I double-checked the config. And to be really
sure, I've looked in the debug logs again. Somewhere at the beginning of the
(very same) connection setup, there is (initiator logfile):
pluto[11791]: "headq": loaded private key matching left certificate
'remotehost1'
pluto[11791]: | counting wild cards for C=XX, O=MyOrg, CN=remotehost1.privlan
is 0
pluto[11791]: | counting wild cards for %fromcert is 0
pluto[11791]: | updating connection from left.host_addr
pluto[11791]: | right host_nexthop 10.0.1.138
pluto[11791]: | update_ends_from_this_host_addr() left.host_port: 0->500
pluto[11791]: | updating connection from right.host_addr
pluto[11791]: | update_ends_from_this_host_addr() right.host_port: 0->500
pluto[11791]: | based upon policy narrowing=yes, the connection is a template.
pluto[11791]: | orienting "headq"
pluto[11791]: | left(THIS) host-address=10.0.1.138 host-port=500 ikeport=0
encap=no
pluto[11791]: | right(THAT) host-address=198.51.100.33 host-port=500
ikeport=0 encap=no
pluto[11791]: "headq": added IKEv2 connection
pluto[11791]: | ike_life: 28800; ipsec_life: 3600s; rekey_margin: 540s;
rekey_fuzz: 100%; keyingtries: 0; replay_window: 32; policy:
RSASIG+ENCRYPT+TUNNEL+PFS+IKEV2_ALLOW_NARROWING+IKE_FRAG_ALLOW+ESN_NO+RSASIG_v1_5+failureDROP
pluto[11791]: | 0.0.0.0/0===10.0.1.138[C=GR, O=MyOrg,
CN=remotehost1.privlan]---10.0.1.1...198.51.100.33<198.51.100.33>[%fromcert]===192.168.1.253/32
pluto[11791]: | delref fd@0x55d4e9c33508(2->1) (in add_connection() at
connections.c:2110)
pluto[11791]: | delref fd@0x55d4e9c33508(1->0) (in whack_handle_cb() at
rcv_whack.c:943)
pluto[11791]: | freeref fd-fd@0x55d4e9c33508 (in whack_handle_cb() at
rcv_whack.c:943)
pluto[11791]: | spent 22.6 (115) milliseconds in whack
To me, it seems that pluto is indeed narrowing down (or I at least read it
saying so).
Phil
_______________________________________________
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
