Re: [Swan-dev] XFRMi routing problems with some special cases
> ok, thanks, I will create some tests for the problematic cases and hopefully > some fixes. I'll push it once I've got a full test result. Long term, should: +#ifdef USE_XFRM_INTERFACE +if (c->xfrmi != NULL && c->xfrmi->if_id != 0) +if (!add_xfrm_interface(c, c->logger)) +return 0; +#endif which is sprinkled over the code base (I found 10 calls?), pushed into the routing / unrouting code proper? ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] XFRMi routing problems with some special cases
On Thu, 2 May 2024 at 05:02, Wolfgang Nothdurft via Swan-dev wrote: > > Hi, > > I am currently trying to sort out a few cases where routes and rules are > not handled correctly. Some internals (i.e., in theory, I'm just including this for completeness) Part of 5.0+'s overhaul was routing.[hc] and that snuck in the easter egg debug=routing, it should make debug logs less painful. Part of 5.1(unreleased) is to have the listen and orient code trigger routing and other changes. This means auto=route can be exactly replicated using <>. While 5.0 was better, it still had some subtle differences. I don't think they matter here and it should be possible to reproduce this problem without auto=route. Having tests rely on auto=route is a pain. With that in mind, the test network looks like https://libreswan.org/wiki/Test_Suite#Current_Network_Diagram I'm guessing this scenario just requires east and west? The structures involved are: - CONNECTION; this manages the kernel policy and routing; with templates an instance responsibility is split - CHILD_SA; this manages the kernel state; a connection has one established CHILD_SA - SPD; manages one selector-pair (subnet<->subnet); a connection has one spd per selector-pair combination > For example, with several tunnels to the same peer and auto=route on one > side, only one route is created, because route-client or route-host is > only called once. > Another Example is that the xfrmi route in the ipsec routing table 50 is > deleted prematurely, although another tunnel still needs it. > Also leftover routes can block a connection in some small side cases. The theory is that updown is run: - prepare once for each selector pair (aka spd) - route is run on an spd when a connection transitions from UNROUTED to any ROUTED state (kernel policy initially installed); - up is run when a connection establishes (kernel state installed) - down is run when Child SA (kernel state) is deleted - unroute is run when tearing out kernel policy (I'll ignore mobike) The code that tries to handle this is spd_owner(). One of its tasks is to look for identical SPDs attached to a connection that still require routing, when one is found it sets .bare_route. Emphasis on the word TRIES. > I solved all these cases more or less with "workarounds" in _updown.xfrm. > > For example, for deleting the table 50 route, my current approach is to > see if ip xfrm state contains multiple states to the same destination > and only delete the route at the last state. > > The question would be if it would make more sense for pluto to take over > the handling of the routing,as with interface-ip, since a reference > counter would also be required here, especially for deleting the routes, > or you just have to check whether the route in table 50 is still needed > by other tunnels to the same destination. In theory that happens now :-( First thing, I think, is to add some tests so we can understand the problem and see why spd_owner() is failing. It might be straight forward bug. > What do you think would be the more reasonable approach here? Sharing SPDs between connections and using them to exactly track kernel policy and routing might help with this quagmire, but I suspect it is more of a way to accelerate the existing logic. When a connection goes to unroute an SPD, it will still need to search through the list of other connections using that SPD and see if one still needs it - like spd_owner() does now. Linux also has a way to set the priority of kernel policy so that identical policies can be installed. That doesn't help with routing though. ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] [Swan-commit] Changes to ref refs/heads/main
On Sat, 20 Apr 2024 at 19:40, Paul Wouters via Swan-dev wrote: > > On Sat, 20 Apr 2024, Andrew Cagney via Swan-commit wrote: > > >libipsecconf: rename internal enum AUTOSTART_ONDEMAND -> AUTOSTART_ROUTE > > This is wrong. The libipsecconf names match the _keywords_ used by auto= > and auto=route has been long obsoleted for auto=ondemand. And auto=ondemand makes no sense when the connection is never-negotiate. I'll define AUTOSTART_ROUTE, AUTOSTART_ONDEMAND, AUTOSTART_START, AUTOSTART_ADD so that pluto can see exactly what the config file contained. > >consistent with other code > > Internal code does not matter much. It is the mapping user option to > variable name that should be consistent in code. It does matter. The closer the alignment between the UI and the internals the easier it is to describe and understand a behaviour. And here all the internals consistently use route/unroute. For instance, routing an RT_UNROUTED connection transitions it to either RT_ROUTED_ONDEMAND or RT_ROUTED_NEVER_NEGOTIATE. ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Bug libreswan-5.0rc2
On Wed, 20 Mar 2024 at 06:42, Armen Dilanyan wrote:
>
> The "discarding" and "dropping" log lines? These aren't really
> errors, or were you not seeing them before?
>
>
> Previously, when RemoteAccess_user1 connected, the event logs showed the ID
> of RemoteAccess_user1
>
> Feb 05 15:02:15 hostname pluto[8882]: "RemoteAccess_user1"[1] 1.1.1.1 #2:
> discarding packet received during asynchronous work (DNS or crypto) in
> STATE_V2_PARENT_R1
> Now, when RemoteAccess_user2 connects, the ID in the event logs is not
> RemoteAccess_user2, but the ID of the first one in the configuration file is
> Mikrotik_Mikrotik1.
> Mar 20 15:23:21 ngfw pluto[15469]: "Mikrotik_Mikrotik1/1x0"[121] 2.2.2.2
> #394: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048
> chosen from remote proposals
> 1:IKE:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;PRF=HMAC_SHA2_256;DH=MODP2048[first-match]
> Mar 20 15:23:21 ngfw pluto[15469]: "Mikrotik_Mikrotik1/1x0"[121] 2.2.2.2
> #394: processed IKE_SA_INIT request from 2.2.2.2:UDP/500 {cipher=AES_CBC_256
> integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
...
> Mar 20 15:23:24 ngfw pluto[15469]: "Mikrotik_Mikrotik1/1x0"[121] 2.2.2.2
> #394: switched to "RemoteAccess_user2"[12] 2.2.2.2
The code's working, but I can understand your surprise.
First the disclaimer:
- because the IKE_SA_INIT contains no identifying information, any
one of the connections that has matching addresses is picked
- then during IKE_AUTH, when the ID and subnet information is
available, the connection is switched to one that fully matches, or
the connection is rejected
The key thing is that when two connections match based on address, the
choice pluto makes isn't documented (you should assume either) and as
we see here, it can change.
And what changed:
In v4, given "con" which turns into con/1x1 ..., con/1x9, which was
initiated was determined by a strange combination of how addconn fed
connections to pluto, and pluto then processed them (in effect, a list
was reversed three times). The result was con/1x1 initiated the
IKE_SA but then con/1x9 was negotiated during IKE_AUTH as the first
child.
In v5, this is all handled within pluto. And as part of this, things
were fixed so that con/1x1 initiates con/1x1 as the first Child SA
(ya). But it does also re-order other stuff.
You could try re-ordering your config file, but I didn't say that.
Andrew
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Bug libreswan-5.0rc2
On Sat, 16 Mar 2024 at 05:03, Armen Dilanyan wrote: > > Hi all. > Hi Andrew. > Yes, you are right, I did not enable debugging. I use one IP address in the > pool, since users must have a static IP address. Configurations are below in > the letter. The debug logs should be gone in mainline. > I also discovered another bug. There were no such errors in version > libreswan-5.0rc1. The "discarding" and "dropping" log lines? These aren't really errors, or were you not seeing them before? ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] Bug libreswan-5.0rc2
See https://github.com/libreswan/libreswan/issues/1653 On Fri, 15 Mar 2024 at 11:27, Andrew Cagney wrote: > > I assume you don't have debugging enabled (ya). > It looks like liveness messages which aren't normally logged. Please > file a bug and thanks for pointing this out. > > On Fri, 15 Mar 2024 at 05:48, Armen Dilanyan via Swan-dev > wrote: > > > > Hi all. > > I have Debian 12.5 operating system installed. > > I compiled and installed Libreswan 5.0~rc2. > > In my logs I get the following messages: > > > > Mar 15 13:42:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:43:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:44:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:45:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:45:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #502's message queue > > Mar 15 13:46:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:46:51 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #515's message queue > > Mar 15 13:47:03 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #508's message queue > > Mar 15 13:47:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:47:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #502's message queue > > Mar 15 13:47:51 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #515's message queue > > Mar 15 13:48:10 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #521's message queue > > Mar 15 13:48:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:49:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:49:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #502's message queue > > Mar 15 13:50:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:51:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:51:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #502's message queue > > Mar 15 13:52:10 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #521's message queue > > Mar 15 13:52:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:53:11 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #521's message queue > > Mar 15 13:53:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:53:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #502's message queue > > Mar 15 13:54:03 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #508's message queue > > Mar 15 13:54:11 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #521's message queue > > Mar 15 13:54:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:55:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #488's message queue > > Mar 15 13:55:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > > SA #502's message queue > > > > Is this a bug or normal? > > ___ > > 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-dev] Bug libreswan-5.0rc2
I assume you don't have debugging enabled (ya). It looks like liveness messages which aren't normally logged. Please file a bug and thanks for pointing this out. On Fri, 15 Mar 2024 at 05:48, Armen Dilanyan via Swan-dev wrote: > > Hi all. > I have Debian 12.5 operating system installed. > I compiled and installed Libreswan 5.0~rc2. > In my logs I get the following messages: > > Mar 15 13:42:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:43:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:44:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:45:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:45:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #502's message queue > Mar 15 13:46:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:46:51 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #515's message queue > Mar 15 13:47:03 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #508's message queue > Mar 15 13:47:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:47:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #502's message queue > Mar 15 13:47:51 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #515's message queue > Mar 15 13:48:10 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #521's message queue > Mar 15 13:48:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:49:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:49:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #502's message queue > Mar 15 13:50:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:51:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:51:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #502's message queue > Mar 15 13:52:10 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #521's message queue > Mar 15 13:52:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:53:11 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #521's message queue > Mar 15 13:53:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:53:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #502's message queue > Mar 15 13:54:03 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #508's message queue > Mar 15 13:54:11 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #521's message queue > Mar 15 13:54:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:55:26 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #488's message queue > Mar 15 13:55:36 hostname pluto[2135]: | adding INFORMATIONAL request to IKE > SA #502's message queue > > Is this a bug or normal? > ___ > 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-dev] state numbers in enduser output?
On Tue, 5 Mar 2024 at 10:23, Paul Wouters via Swan-dev
wrote:
>
> On Tue, 5 Mar 2024, Andrew Cagney via Swan-commit wrote:
>
> > Date: Mon Mar 4 20:15:11 2024 -0500
> >
> >ikev2: drop and NOT sending notify
> >
> >it's redundant and confusing vis:
> > "west-cuckold" #4: sent INFORMATIONAL request to delete IKE SA
> > "west-cuckold" #5: ESP traffic information: in=0B out=0B
> >-"west-cuckold" #4: deleting IKE SA (IKE_SA_DELETE) and NOT sending
> > notification
> >+"west-cuckold" #4: deleting IKE SA (STATE_IKESA_DEL)
>
> I'm okay with this, but I thought we were also aiming at removing all
> state names from user output? Eg why not "+"west-cuckold" #4: deleting IKE SA"
Fair question (I wondered if the example was a little misleading).
STATE_IKESA_DEL is the state's story :-( When it isn't bogus, it is
somewhat useful vis:
"westnet-eastnet-k2" #1: STATE_V2_PARENT_I1: 3 second timeout
exceeded after 2 retransmits. No response (or no acceptable response)
to our first IKEv2 message
"westnet-eastnet-k2" #1: connection is supposed to remain up; revival
attempt 1 scheduled in 0 seconds
"westnet-eastnet-k2" #1: IMPAIR: revival: skip scheduling revival event
-"westnet-eastnet-k2" #1: deleting IKE SA (PARENT_I1) and NOT sending
notification
+"westnet-eastnet-k2" #1: deleting IKE SA (sent IKE_SA_INIT request)
"private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #1: processed
IKE_SA_INIT response from 192.1.2.23:UDP/500 {cipher=AES_GCM_16_256
integ=n/a prf=HMAC_SHA2_512 group=DH19}, initiating IKE_AUTH
"private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #1: IKE SA
authentication request rejected by peer: AUTHENTICATION_FAILED
"private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #1: encountered
fatal error in state STATE_V2_PARENT_I2
-"private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #1: deleting IKE SA
(PARENT_I2) and NOT sending notification
+"private-or-clear#192.1.2.0/24"[1] ...192.1.2.23 #1: deleting IKE SA
(sent IKE_AUTH request)
but it could easily be dropped.
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
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
Re: [Swan-dev] What does "missing v2CP reply" mean?
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
Re: [Swan-dev] NAT and intermediate exchange
On Thu, 22 Feb 2024 at 13:43, Paul Wouters via Swan-dev wrote: > > On Thu, 22 Feb 2024, Andrew Cagney via Swan-commit wrote: > > > New commits: > > commit 8f2151aab6084561bdeb8c49206ee238b508eecc > > Author: Andrew Cagney > > Date: Thu Feb 22 10:58:13 2024 -0500 > > > >ikev2: drop code checking for NAT during IKE_INTERMEDIATE exchange > > > >NAT happens during IKE_SA_INIT; follow-up: > > pluto: do not allow nic-offload=packet with encapsulation=yes > > I checked RFC9242 and you are correct. Right. According to the basic IKEv2 RFC, NAT is all handled during IKE_SA_INIT. Hence, seeing changes to ikev2_ike_intermediate.[hc] caught my eye (that and that I'd previously removed remarkably similar code in ikev2_ike_auth.[hc]). ___ Swan-dev mailing list Swan-dev@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan-dev
Re: [Swan-dev] labeled TS don't search for a connection ?
On Tue, 20 Feb 2024 at 21:16, Paul Wouters via Swan-dev wrote: > > > I see this commit: > > commit f198add4b08640d1b67aef19168998070b65b725 > Author: Andrew Cagney > Date: Tue Feb 20 20:25:33 2024 -0500 > > ikev2: when responding to labeled TS don't search for a connection > > only possible match is the IKE SAs (note that at this point > the Child SA is sharing the IKE SAs connection). > > > I am confused by this? There could me multiple connections with different > labels that end up sharing an IKE SA ? eg: No. With labeled IPsec the IKE SA has a CK_LABELED_PARENT connection and each Child SA has a unique CK_LABELED_CHILD connection instantiated from the IKE SA's CK_LABELED_PARENT). The IKE SA's CK_LABELED_PARENT owns the on-demand policy while the Child SA's CK_LABELED_CHILD owns a state/policy pair. The problem is that at this point in the code that split hasn't happened - the IKE and Child SA share a single connection - which means Child code trying to set the route owner can end up scribbling on the wrong connection. > conn labeled-1 > also=west-east > type=transport > policy-label=system_u:object_r:ipsec_spd_t:s0 > > conn labeled-2 > also=west-east > type=transport > policy-label=system_u:object_r:TOP_SECRET:s0 > > Paul > ___ > 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-dev] What does "missing v2CP reply" mean?
> Feb 15 06:15:48 saledortvm2 pluto[70624]: "server01.cnf.com" #2: processing
> decrypted IKE_AUTH request: SK{IDi,CERT,AUTH,CP,SA,TSi,TSr}
notice how the client sent a CP payload in the request (CP_REQUEST to be exact).
but
> #2: missing v2CP reply, not attempting to setup child SA
> #1: IKE SA established but initiator rejected Child SA response
the responder never came back with a CP_RESPONSE, which is required to
create the Child SA. Hence no child leaving only the IKE SA.
What I'm not clear on is why the initiator asked for CP, and the
responder declined its request.
Andrew
___
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
