[Swan-commit] Changes to ref refs/heads/main
New commits: commit d50778d1963733eb92f97c6d3d3443f89a1c3aaf Author: Andrew Cagney Date: Tue Feb 27 23:02:29 2024 -0500 ikev2: ikev2: in CREATE_CHILD_SA add/use reject_CREATE_CHILD_SA_response() Note that this preserves the current (broken) behaviour where the rejected child isn't deleted. ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 6b89b11c5c3955778eb02738cebfb3b44b992eb7 Author: Andrew Cagney Date: Tue Feb 27 21:26:10 2024 -0500 testing kvm: include failures in all.console.txt ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 8d7a8dc0749a298c1408a4110369c526d08fb115 Author: Andrew Cagney Date: Tue Feb 27 20:21:01 2024 -0500 testing kvm: replace the run() try catch with return codes ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit e24422366a34ec51f48e78d27612476e35d656ab Author: Andrew Cagney Date: Tue Feb 27 11:48:45 2024 -0500 ikev2: in CREATE_CHILD_SA add/use reject_CREATE_CHILD_SA_request() ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 07ad99e165fc7698dfc0e582320a8151726039ef Author: Andrew Cagney Date: Tue Feb 27 18:01:23 2024 -0500 testing kvm: re-order all.console.verbose.txt code ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan] Possible to setup multiple connections, partly behind NAT?
> > 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
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 9be7671e121eee4d5d707b1a994cef5ef019b7a8 Author: Andrew Cagney Date: Tue Feb 27 09:20:16 2024 -0500 testing kvm: rename "verbose_txt"->"all_verbose_txt" ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit cada9054e8afdd1465eed8df1ce2e7e2dbca8c37 Author: Andrew Cagney Date: Tue Feb 27 11:29:00 2024 -0500 ikev2: use ..._v2SA_...() when refering to IKEv2's SA payload Rename the confusing ..._childs_sa_...() and ..._child_sa_...(). ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan-dev] What does "missing v2CP reply" mean?
On Tue, 27 Feb 2024 at 05:10, Brady Johnson wrote: > > We tried several changes to the client nmstate configuration. Setting "ipv4: > dhcp: false" caused a configuration error in nmstate. We have created a bug > for that and the nmstate team is working on it. I didn't see it here https://github.com/nmstate/nmstate/issues ? I'd like to track it, i filed https://github.com/nmstate/nmstate/issues/2568 Is there an easy way to display what nmstate generated? > Then, we tried with the same client nmstate configuration, but added > "leftmodecfgclient: false" and this allowed us to establish the tunnel. > > So, apparently, the "ipv4: dhcp: true" nmstate configuration causes the > client to request IP addresses and DNS. And setting "leftmodecfgclient: > false" overrides that in the nmstate configuration. Yes. I suspect it is adding leftmodecfgclient=true to the generated config file ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 81293526ebecda9ef9d2a98eca9eaea25f9d80ad Author: Andrew Cagney Date: Tue Feb 27 13:19:27 2024 -0500 testing sanitizers: trim guest-prompt-double.sed no longer needs to fix: west # west# in all.console.verbose.txt ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan-dev] What does "missing v2CP reply" mean?
Right, but for this use case we didnt want the server to assign an IP to the client. Thanks, *Brady Johnson* Principal Software Engineer Telco Verification Ecosystems Engineering brady.john...@redhat.com On Tue, Feb 27, 2024 at 4:40 PM Paul Wouters wrote: > On Tue, 27 Feb 2024, Brady Johnson via Swan-dev wrote: > > > We tried several changes to the client nmstate configuration. Setting > "ipv4: dhcp: false" caused a configuration error in nmstate. > > We have created a bug for that and the nmstate team is working on it. > > Then, we tried with the same client nmstate configuration, but added > "leftmodecfgclient: false" and this allowed us to establish the > > tunnel. > > > > So, apparently, the "ipv4: dhcp: true" nmstate configuration causes the > client to request IP addresses and DNS. And setting > > "leftmodecfgclient: false" overrides that in the nmstate configuration. > > Note that for libreswan 5.0, the client should use something like: > > leftsubnet=0.0.0.0/0,::/0 > > And the server should use something like: > > rightaddresspool=100.64.13.0/24,2a03:6000:1005::/97 > > and it will hand out both v4 and v6 addresses on the same single IPsec > SA. > > Paul > > ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan] Possible to setup multiple connections, partly behind NAT?
On Tue, 27 Feb 2024, Phil Nightowl wrote:
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
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.
Paul
___
Swan mailing list
Swan@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan-dev] What does "missing v2CP reply" mean?
On Tue, 27 Feb 2024, Brady Johnson via Swan-dev wrote: We tried several changes to the client nmstate configuration. Setting "ipv4: dhcp: false" caused a configuration error in nmstate. We have created a bug for that and the nmstate team is working on it. Then, we tried with the same client nmstate configuration, but added "leftmodecfgclient: false" and this allowed us to establish the tunnel. So, apparently, the "ipv4: dhcp: true" nmstate configuration causes the client to request IP addresses and DNS. And setting "leftmodecfgclient: false" overrides that in the nmstate configuration. Note that for libreswan 5.0, the client should use something like: leftsubnet=0.0.0.0/0,::/0 And the server should use something like: rightaddresspool=100.64.13.0/24,2a03:6000:1005::/97 and it will hand out both v4 and v6 addresses on the same single IPsec SA. Paul ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
[Swan-commit] Changes to ref refs/heads/main
New commits: commit bdc217083b4348ba3d75ac4fac48691913dd1f10 Author: Andrew Cagney Date: Tue Feb 27 09:39:06 2024 -0500 testing: delete unused sanitizers host-dig-sanitize.sed ipsec-ver-sanitize.sed local-tree.sed no-empty.sed pfkey-sanitize.sed pfkey-time-cleanup.sed private-key-sanitize.sed systemd-services.sed ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits:
commit 6909831d45597351ee9c06fd2754e70eaf316503
Author: Andrew Cagney
Date: Tue Feb 27 08:44:55 2024 -0500
id: clarify atoid() a little
commit 38cb83a3bb3a6e2dd7fbff67301d86ba4e07b0ef
Author: Andrew Cagney
Date: Tue Feb 27 08:43:40 2024 -0500
testing: in ikev1-l2tp-03-two-interfaces drop rightid=%cert
bogus; in 4.x was interpreted as rightid=${right}; in 5.x it
is rejected
___
Swan-commit mailing list
Swan-commit@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit cd03247ce5f8ea5035b957bb3796ef09b2ec5327 Author: Andrew Cagney Date: Tue Feb 27 08:32:46 2024 -0500 logging: add pdbgf(), use ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
[Swan-commit] Changes to ref refs/heads/main
New commits: commit 709f41c1abab22b00a2544308f7d80e712c4a5db Author: Andrew Cagney Date: Tue Feb 27 08:26:13 2024 -0500 testing: update impair-install-ipsec-sa-* expect TEMPORARY_FAILURE ___ Swan-commit mailing list Swan-commit@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-commit
Re: [Swan-dev] What does "missing v2CP reply" mean?
We tried several changes to the client nmstate configuration. Setting "ipv4: dhcp: false" caused a configuration error in nmstate. We have created a bug for that and the nmstate team is working on it. Then, we tried with the same client nmstate configuration, but added "leftmodecfgclient: false" and this allowed us to establish the tunnel. So, apparently, the "ipv4: dhcp: true" nmstate configuration causes the client to request IP addresses and DNS. And setting "leftmodecfgclient: false" overrides that in the nmstate configuration. Thanks, *Brady Johnson* Principal Software Engineer Telco Verification Ecosystems Engineering brady.john...@redhat.com On Thu, Feb 22, 2024 at 10:04 PM Andrew Cagney via Swan-dev < swan-dev@lists.libreswan.org> wrote: > On Fri, 16 Feb 2024 at 10:18, Tuomo Soini via Swan-dev > wrote: > > > > On Fri, 16 Feb 2024 16:12:20 +0100 > > Brady Johnson via Swan-dev wrote: > > > > > I included the configuration in the original email, and it did not > > > include "narrowing", nor "leftmodecfgclient". I'll check if either of > > > those are set by default. > > > > My guess is that "dhcp" in NetworkManager configuration might cause > > this. > > I didn't see a hint of that in the posted config. > > How does <> line up with ikev2_cp.c and the > logic for when to send/receive a CP payload? > > > > Would it have been better to send this email to "Libreswan users"? > > > > Maybe? > > I don't think it matters. > ___ > Swan-dev mailing list > Swan-dev@lists.libreswan.org > https://lists.libreswan.org/mailman/listinfo/swan-dev > > ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan] Possible to setup multiple connections, partly behind NAT?
Out of other ideas, I resorted to debug logs. To me, the more interesting
part seems to be the initiator, since the responder reports to have
established a tunnel successfully:
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}
On the initiator, the (probably) critical part reads
pluto[11791]: "headq"[1] 198.51.100.33 #1: authenticated using RSA with SHA2_512
pluto[11791]: | #1 spent 2.36 (2.36) milliseconds in ikev2_verify_rsa_hash()
pluto[11791]: | parent state #1: PARENT_I2(open IKE SA) =>
ESTABLISHED_IKE_SA(established IKE SA)
pluto[11791]: | #1 will start re-keying in 27807 seconds with margin of 993
seconds (attempting re-key)
pluto[11791]: | state #1 deleting .st_event EVENT_SA_REPLACE
pluto[11791]: | delref libevent@0x55d4e9c53088(1->0) (in libevent_free() at
server.c:985)
pluto[11791]: | delref pe@0x55d4e9c49018(1->0) (in free_event_entry() at
server.c:476)
pluto[11791]: | event_schedule: newref EVENT_SA_REKEY-pe@0x55d4e9c49018
pluto[11791]: | inserting event EVENT_SA_REKEY, timeout in 27807 seconds for #1
pluto[11791]: | newref libevent@0x55d4e9c5dd68(0->1) (in libevent_malloc() at
server.c:969)
pluto[11791]: | pstats #1 ikev2.ike established
pluto[11791]: | FOR_EACH_STATE_... in nat_traversal_ka_event (for_each_state)
pluto[11791]: | skipping NAT-T KEEP-ALIVE: #2 is not current IKE SA
pluto[11791]: | we are behind NAT: sending of NAT-T KEEP-ALIVE for conn headq
pluto[11791]: | ka_event: send NAT-KA to 198.51.100.33:4500 (state=#1)
pluto[11791]: | sending NAT-T Keep Alive
pluto[11791]: | sending 1 bytes for NAT-T Keep Alive through enp2s0 from
10.0.1.138:4500 to 198.51.100.33:4500 using UDP (for #1)
pluto[11791]: | ff
pluto[11791]: | global one-shot timer EVENT_NAT_T_KEEPALIVE scheduled in 20
seconds
pluto[11791]: | TSi: parsing 1 traffic selectors
pluto[11791]: | ***parse IKEv2 Traffic Selector Header:
pluto[11791]: |TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7)
pluto[11791]: |IP Protocol ID: ALL (0x0)
pluto[11791]: |length: 16 (00 10)
pluto[11791]: | parse IKEv2 IP Traffic Selector port range:
pluto[11791]: |start port: 0 (00 00)
pluto[11791]: |end port: 65535 (ff ff)
pluto[11791]: | parsing 4 raw bytes of IKEv2 Traffic Selector Header into TS IP
start
pluto[11791]: | TS IP start
pluto[11791]: | 5e c7 62 37
pluto[11791]: | parsing 4 raw bytes of IKEv2 Traffic Selector Header into TS IP
end
pluto[11791]: | TS IP end
pluto[11791]: | 5e c7 62 37
pluto[11791]: | TSi: parsed 1 traffic selectors
pluto[11791]: | TSr: parsing 1 traffic selectors
pluto[11791]: | ***parse IKEv2 Traffic Selector Header:
pluto[11791]: |TS type: IKEv2_TS_IPV4_ADDR_RANGE (0x7)
pluto[11791]: |IP Protocol ID: ALL (0x0)
pluto[11791]: |length: 16 (00 10)
pluto[11791]: | parse IKEv2 IP Traffic Selector port range:
pluto[11791]: |start port: 0 (00 00)
pluto[11791]: |end port: 65535 (ff ff)
pluto[11791]: | parsing 4 raw bytes of IKEv2 Traffic Selector Header into TS IP
start
pluto[11791]: | TS IP start
pluto[11791]: | c0 a8 85 f0
pluto[11791]: | parsing 4 raw bytes of IKEv2 Traffic Selector Header into TS IP
end
pluto[11791]: | TS IP end
pluto[11791]: | c0 a8 85 f0
pluto[11791]: | TSr: parsed 1 traffic selectors
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
pluto[11791]: | job 4 for #2: initiator decoding certificates (decode
certificate payload): calling cleanup function 0x55d4e84f4250
pluto[11791]: | delref mdp@0x55d4e9c47808(2->1) (in cert_decode_cleanup() at
cert_decode_helper.c:195)
pluto[11791]: | delref root_certs@0x55d4e9c470b8(2->1) (in
cert_decode_cleanup() at cert_decode_helper.c:196)
pluto[11791]: | delref logger@0x55d4e9c56e78(1->0) (in handle_helper_answer()
at server_pool.c:457)
pluto[11791]: | delref fd@NULL (in free_logger() at log.c:677)
pluto[11791]: | delref fd@NULL (in free_logger() at log.c:678)
pluto[11791]: | #2 complete_v2_state_transition()
PARENT_I2->ESTABLISHED_CHILD_SA with status STF_FAIL+v2N_TS_UNACCEPTABLE;
.st_v2_transition=NULL
pluto[11791]: "headq"[1] 198.51.100.33 #2: state transition 'Initiator: process
IKE_AUTH response' failed with v2N_TS_UNACCEPTABLE
pluto[11791]: | delref mdp@0x55d4e9c47808(1->0) (in resume_handler() at
server.c:733)
pluto[11791]: | delref logger@0x55d4e9c57138(1->0) (in resume_handler() at
server.c:733)
pluto[11791]: | delref fd@NULL (in free_logger() at log.c:677)
pluto[11791]: | delref fd@NULL (in free_logger() at log.c:678)
pluto[11791]: | #2
