Andrew pointed out a use case that is not covered yet, which is "transport
mode when host==client". This is caused by the following check in the
jam_end_client() function:
if (selector_eq_address(this->client, this->host->addr)) {
return;
}
This is not only an issue in transport mode, but also in tunnel mode with
either host-to-subnet or subnet-to-host.
I will perform this check in the whack_briefconnectionstatus.c code and I
wanted to propose one of the following options:
OPTION 1:
---------------
transport mode when host == client for both the local and remote:
000 from 172.22.18.102 to 172.22.18.101 (0B/0B) "gwn02_transport_tun",
reqid=16388
tunnel mode with host-to-subnet:
000 172.22.18.102 <==> 172.16.10.0/24 from 172.22.18.102 to 172.22.18.101
(0B/0B) "gwn02_transport_tun", reqid=16388
tunnel mode with subnet-to-host:
000 172.16.20.0/24 <==> 172.22.18.101 from 172.22.18.102 to 172.22.18.101
(0B/0B) "gwn02_transport_tun", reqid=16388
OPTION 2:
---------------
transport mode when host == client for both the local and remote:
000 host <==> host from 172.22.18.102 to 172.22.18.101 (0B/0B)
"gwn02_transport_tun", reqid=16388
tunnel mode with host-to-subnet:
000 host <==> 172.16.10.0/24 from 172.22.18.102 to 172.22.18.101 (0B/0B)
"gwn02_transport_tun", reqid=16388
tunnel mode with subnet-to-host:
000 172.16.20.0/24 <==> host from 172.22.18.102 to 172.22.18.101 (0B/0B)
"gwn02_transport_tun", reqid=16388
I prefer OPTION 2. Does anybody have any preferences?
Regards,
*Brady Johnson*
On Fri, Nov 3, 2023 at 2:58 PM Brady Johnson <brady...@redhat.com> wrote:
>
> Ok, I pushed the requested changes to the PR.
>
> Now the command only displays active connections. Here is the output:
>
> ipsec --briefconnectionstatus
> 000 Connection list:
> 000
> 000 172.16.20.0/24 <==> 172.16.10.0/24 from 172.22.18.102 to
> 172.22.18.101 (252B/252B) "vpnclient.gwn02.xyz.com", reqid=16388
> 000
> 000 Total IPsec connections: loaded 2, active 1
>
> Notice the footer information, "loaded 2, active 1". I loaded one of
> Tuomi's template connections to demonstrate it only shows active
> connections.
>
> The "ipsec --connectionstatus" shows all of the connections, active or
> otherwise:
>
> ipsec --connectionstatus
> 000 Connection list:
> 000
> 000 "bleve-v4": 0.0.0.0/0===193.65.2.90[O=SMB
> <http://0.0.0.0/0===193.65.2.90%5BO=SMB>,
> CN=vpnclient.gwn02.smb.com,MS+S=C]---193.65.2.89...%any[C=FI,
> L=Vihti, O=Foobar Oy, OU=Security, CN=Tuomo Soini, E=t...@foobar.fi,+MC+S=C];
> unoriented; my_ip=193.65.3.126; their_ip=unset; reqid=16392;
> ...
> 000 "vpnclient.gwn02.xyz.com": 172.16.20.0/24===172.22.18.102[O=XYZ
> <http://172.16.20.0/24===172.22.18.102%5BO=XYZ>, CN=
> vpnclient.gwn02.xyz.com]...172.22.18.101[O=XYZ, CN=vpnserver.gwn01.xyz.com
> ]===172.16.10.0/24; routed-tunnel; my_ip=unset; their_ip=unset;
> reqid=16388;
> ...
>
> Regards,
>
> Brady
>
>
>
> On Thu, Nov 2, 2023 at 12:59 PM Paul Wouters <p...@nohats.ca> wrote:
>
>> On Thu, 2 Nov 2023, Brady Johnson wrote:
>>
>> > Here is the PR for this change [0]. I'm not sure why, but the PR is
>> getting a semgrep failure in github.
>>
>> The semgrep issue is unrelated, a fix should be there shortly.
>>
>> > The output is the following:
>> >
>> > $ ipsec --briefconnectionstatus
>> > 000 Connection list:
>> > 000
>> > 000 172.16.20.0/24 @ 172.22.18.102 (2KiB in) <==> 172.16.10.0/24
>> @ 172.22.18.101 (1KiB in)
>> > vpnclient.gwn02.xyz.com, reqid=16388
>>
>> Personally, I strongly prefer the first two things are source/mask <=>
>> dest/mask,
>> as that is the core info people usually want to see/confirm. Having this
>> split in two makes this much harder to read. If you want to avoid adding
>> up the counters, perhaps this format could be considered:
>>
>> 000 172.16.20.0/24 <=> 172.16.10.0/24 from 172.22.18.102 to
>> 172.22.18.101 (2KiB/1KiB) vpnclient.gwn02.xyz.com, reqid=16388
>>
>> > Notice I added the reqid to the output of the "ipsec connectionstatus"
>> command.
>>
>> That's good, thanks.
>>
>> > Can I get a review of this PR, please.
>> >
>> > [0] https://github.com/libreswan/libreswan/pull/1350
>>
>> Left the comments there too.
>>
>> Paul
>>
>>
_______________________________________________
Swan-dev mailing list
Swan-dev@lists.libreswan.org
https://lists.libreswan.org/mailman/listinfo/swan-dev
