From iiordanov at gmail.com  Mon Mar  1 06:07:42 2021
From: iiordanov at gmail.com (i iordanov)
Date: Mon, 1 Mar 2021 01:07:42 -0500
Subject: Nested Wireguard tunnels not working on Android and Windows
In-Reply-To: <65365aa6-cdd0-f9dc-f894-3a040ca596ae@aaronmdjones.net>
References: <CAMS0tn2Pq65UAVWqjV6mNd1hGqvUxVhVgmR3s2h+kh=XF8jyKA@mail.gmail.com>
 <E8F8664E-3C8A-45B9-B9B8-1A1E2873289B@carmickle.com>
 <65365aa6-cdd0-f9dc-f894-3a040ca596ae@aaronmdjones.net>
Message-ID: <CAMS0tn0k=7aVstO7Nnn1zZDUypuE2sWidS3uT+04=7rs6+YjGQ@mail.gmail.com>

Hi Aaron, Frank,

Thanks for your replies. For some reason, gmail had decided Frank's
original reply was spam, I apologize for missing it. The first message
in response to mine I received was Aaron's. Frank, after retrieving
your message, yes you understanding is correct.

Yes, I have done packet capture and indeed, the setup works correctly
on Linux and Mac, whereas it does not work under Android and Windows.
What can I do to help diagnose, debug and/or resolve this issue?

Cheers and thanks!
iordan


On Sun, Feb 28, 2021 at 5:17 PM Aaron Jones <me at aaronmdjones.net> wrote:
>
> On 27/02/2021 17:16, Frank Carmickle wrote:
> > Iordan,
> >
> > You say that it's possible to run a nested configuration on
> > Linux and Macos with just a single interface each. Have you
> > done a packet capture to prove that that is in fact what is
> > happening? That doesn't seem like how it would act given the
> > design goals.
>
> Nesting (Using one of Peer A's AllowedIPs as Peer B's Endpoint) does
> work within the same WireGuard interface, at least on Linux.
>
>


--
The conscious mind has only one thread of execution.

From laura.zelenku at wandera.com  Mon Mar  1 14:08:26 2021
From: laura.zelenku at wandera.com (Laura Zelenku)
Date: Mon, 1 Mar 2021 15:08:26 +0100
Subject: Handshake state collision between parralel RoutineHandshake
 threads
In-Reply-To: <CAHmME9oOKvMqvSw_CrjhiWU+R60AEVxLYzoaC8W7F7D5vWgWvA@mail.gmail.com>
References: <27D86318-AED9-49EC-94EE-1FFC806533DC@wandera.com>
 <CAHmME9oOKvMqvSw_CrjhiWU+R60AEVxLYzoaC8W7F7D5vWgWvA@mail.gmail.com>
Message-ID: <92B58443-8904-417B-A866-7BD2C6240B42@wandera.com>

Hi Jason,
I?ll try to explain the issue.

For incomming hanshake, the `handshake.state` is changing in the following way:
1. set state handshakeInitiationConsumed
2. check the state is handshakeInitiationConsumed otherwise "handshake initiation must be consumed first? error
3. set state handshakeResponseCreated
4. check the state is handshakeResponseCreated, otherwise "invalid state for keypair derivation? error
5. set state handshakeZeroed

For outgoing handshake the `handshake.state` is changing:
1. set state handshakeInitiationCreated
2. <sending handshake and waiting for response>
3. check the state is handshakeInitiationCreated, otherwise skip the packet
4. set state handshakeResponseConsumed
5. check the state is handshakeResponseConsumed, otherwise "invalid state for keypair derivation? error
6. set state handshakeZeroed

Usually only ?client? is sending handshake initiations and the ?server? responding. But in case some delay (e.g. cause by some network issues mainly for mobile devices) the ?server? can start sending handshake initiations (expiredNewHandshake or expiredRetransmitHandshake timers). In this time the client and server are sending hanshake initiations against each other. "go device.RoutineHandshake()? is running in multiple threads. `handshake.state` is defined per peer. Two threads (RoutineHandshake) can process both handshakes (incomming, outgoing) in the same time and these threads are working with shared resource, handshake.state. Because the routine is expecting state that was set before and the second thread can modify the state, the routine can fail on checking the expected handshake.state.
This is happening to us. We are getting error "handshake initiation must be consumed first?. handshakeInitiationConsumed is expected but handshakeZeroed is actually set (set by different thread). The error is logged on error level (Failed to create response message).

Hope this will help to understand the issue well.

Laura


> On 25 Feb 2021, at 12:23, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> Hi Laura,
> 
> I'm not sure this is actually a problem. The latest handshake message
> should probably win the race. I don't see state machine or data
> corruption here, but just one handshake interrupting another, which is
> par for the course with WireGuard.
> 
> Or have I overlooked something important in the state machine implementation?
> 
> Jason


-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

From frank at carmickle.com  Mon Mar  1 14:44:26 2021
From: frank at carmickle.com (Frank Carmickle)
Date: Mon, 1 Mar 2021 09:44:26 -0500
Subject: Nested Wireguard tunnels not working on Android and Windows
In-Reply-To: <CAMS0tn0k=7aVstO7Nnn1zZDUypuE2sWidS3uT+04=7rs6+YjGQ@mail.gmail.com>
References: <CAMS0tn2Pq65UAVWqjV6mNd1hGqvUxVhVgmR3s2h+kh=XF8jyKA@mail.gmail.com>
 <E8F8664E-3C8A-45B9-B9B8-1A1E2873289B@carmickle.com>
 <65365aa6-cdd0-f9dc-f894-3a040ca596ae@aaronmdjones.net>
 <CAMS0tn0k=7aVstO7Nnn1zZDUypuE2sWidS3uT+04=7rs6+YjGQ@mail.gmail.com>
Message-ID: <43EFA67E-34E0-4E33-A2FB-EBD42002F1AB@carmickle.com>

Iordan,

> On Mar 1, 2021, at 1:07 AM, i iordanov <iiordanov at gmail.com> wrote:
> 
> Hi Aaron, Frank,
> 
> Thanks for your replies. For some reason, gmail had decided Frank's
> original reply was spam, I apologize for missing it. The first message
> in response to mine I received was Aaron's. Frank, after retrieving
> your message, yes you understanding is correct.
> 
> Yes, I have done packet capture and indeed, the setup works correctly
> on Linux and Mac, whereas it does not work under Android and Windows.

Maybe it's a bug and not a feature? It seems to me that you would have no way of setting the MTU on the inner tunnel.

> What can I do to help diagnose, debug and/or resolve this issue?

Is there a reason why you can't try multiple interfaces?

--FC

> Cheers and thanks!
> iordan
> 
> 
> On Sun, Feb 28, 2021 at 5:17 PM Aaron Jones <me at aaronmdjones.net> wrote:
>> 
>> On 27/02/2021 17:16, Frank Carmickle wrote:
>>> Iordan,
>>> 
>>> You say that it's possible to run a nested configuration on
>>> Linux and Macos with just a single interface each. Have you
>>> done a packet capture to prove that that is in fact what is
>>> happening? That doesn't seem like how it would act given the
>>> design goals.
>> 
>> Nesting (Using one of Peer A's AllowedIPs as Peer B's Endpoint) does
>> work within the same WireGuard interface, at least on Linux.
>> 
>> 
> 
> 
> --
> The conscious mind has only one thread of execution.


From iiordanov at gmail.com  Mon Mar  1 20:09:03 2021
From: iiordanov at gmail.com (i iordanov)
Date: Mon, 1 Mar 2021 15:09:03 -0500
Subject: Nested Wireguard tunnels not working on Android and Windows
In-Reply-To: <43EFA67E-34E0-4E33-A2FB-EBD42002F1AB@carmickle.com>
References: <CAMS0tn2Pq65UAVWqjV6mNd1hGqvUxVhVgmR3s2h+kh=XF8jyKA@mail.gmail.com>
 <E8F8664E-3C8A-45B9-B9B8-1A1E2873289B@carmickle.com>
 <65365aa6-cdd0-f9dc-f894-3a040ca596ae@aaronmdjones.net>
 <CAMS0tn0k=7aVstO7Nnn1zZDUypuE2sWidS3uT+04=7rs6+YjGQ@mail.gmail.com>
 <43EFA67E-34E0-4E33-A2FB-EBD42002F1AB@carmickle.com>
Message-ID: <CAMS0tn2FXkzFHgMgkDwYvD2Fhrxb_PjMNDuV54sL9-ZhTijS7A@mail.gmail.com>

Hi Frank,

On Mon, Mar 1, 2021 at 9:42 AM Frank Carmickle <frank at carmickle.com> wrote:
> Maybe it's a bug and not a feature? It seems to me that you would have no way of setting the MTU on the inner tunnel.

That's true - other than inefficient packet fragmentation, is there
anything else that would be an issue?

> Is there a reason why you can't try multiple interfaces?

I cannot bring up more than a single interface on Android. I am not
sure about interface management on Windows with wg.exe, but
wireguard.exe certainly does not permit multiple interfaces to be
brought up.

Thanks!
iordan


-- 
The conscious mind has only one thread of execution.

From peter.whisker at gmail.com  Tue Mar  2 08:03:38 2021
From: peter.whisker at gmail.com (Peter Whisker)
Date: Tue, 2 Mar 2021 08:03:38 +0000
Subject: Wireguard Win10 Client not work through an openVPN tunnel on the same
 machine
In-Reply-To: <CAL5yamu4tnxCS58JbTqPtO4W51CdieZ_S0ntk7VNRV044mLmcQ@mail.gmail.com>
References: <CAL5yamu4tnxCS58JbTqPtO4W51CdieZ_S0ntk7VNRV044mLmcQ@mail.gmail.com>
Message-ID: <115f4409-2fee-6332-0eb9-598421d6eb5b@gmail.com>

This may be because Wireguard binds to the default route interface which 
is not correct if you want to use another route such as your OpenVPN. It 
also fails with PulseSecure VPN.

As discussed here in the past month, removing the code which binds and 
recompiling Wireguard fixes the problem.

Peter

On Sun, 28 Feb 2021, 22:17 Heiko Kendziorra, <kendziorra at dresearch-fe.de 
<mailto:kendziorra at dresearch-fe.de>> wrote:

    Machine A in Intranet Windows 10 Prof Version : 20H2
    Address 172.1.2.3
    Firewall is open for? webserver und wireguard (8080 tcp, 44444 udp)
    is WireguardServer? Version 0.3.7

    wg.conf:
    PublicKey = A8C8+bRYaqu2MKs2SpwuRRgmwqItYwFFJjk77UtUUxU=
    [Interface]
    PrivateKey = ********************************
    ListenPort = 44444
    Address = 192.168.44.44/32 <http://192.168.44.44/32>
    [Peer]
    PublicKey = JkacJ6IYPUgCOv+OdHN6ZMJ+JRZr6V5/kDzthil/CUs=
    AllowedIPs = 192.168.44.4/32 <http://192.168.44.4/32>
    PersistentKeepalive = 25
    --------------------------------------------------------------------------------
    Machine B extern over openVPN connected with the Intranet Windows 10
    Prof Version : 20H2? (OpenVPN Client running on B)
    Address 172.11.12.13 could reach A over Routing? (Test: Webserver on
    A: 172.1.2.3:8080 <http://172.1.2.3:8080>)
    is WireguardClient Version 0.3.7

    wg.conf:
    PublicKey = JkacJ6IYPUgCOv+OdHN6ZMJ+JRZr6V5/kDzthil/CUs=
    [Interface]
    PrivateKey = **********************
    Address = 192.168.44.4/32 <http://192.168.44.4/32>

    [Peer]
    PublicKey = A8C8+bRYaqu2MKs2SpwuRRgmwqItYwFFJjk77UtUUxU=
    AllowedIPs = 192.168.44.44/32 <http://192.168.44.44/32>
    Endpoint = 172.16.41.20:44444 <http://172.16.41.20:44444>
    PersistentKeepalive = 25
    --------------------------------------------------------------------------------

    Result after Activation
    The Client B could not estable a working Wireguard-Connetion to A :

    Protokoll Server:
    2021-02-27 10:53:02.636: [TUN] [44444] Startup complete
    2021-02-27 10:53:03.615: [TUN] [44444] peer(Jkac?/CUs) - Received
    handshake initiation
    2021-02-27 10:53:03.615: [TUN] [44444] peer(Jkac?/CUs) - Sending
    handshake response
    2021-02-27 10:53:07.821: [TUN] [44444] peer(Jkac?/CUs) - Handshake did
    not complete after 5 seconds, retrying (try 2)
    2021-02-27 10:53:11.480: [MGR] [Wintun] IsPoolMember: Reading pool
    devpkey failed, falling back: Element nicht gefunden. (Code
    0x00000490)
    2021-02-27 10:53:28.626: [TUN] [44444] peer(Jkac?/CUs) - Sending
    handshake initiation
    2021-02-27 10:53:33.794: [TUN] [44444] peer(Jkac?/CUs) - Handshake did
    not complete after 5 seconds, retrying (try 2)
    2021-02-27 10:53:33.794: [TUN] [44444] peer(Jkac?/CUs) - Sending
    handshake initiation
    2021-02-27 10:53:39.094: [TUN] [44444] peer(Jkac?/CUs) - Handshake did
    not complete after 5 seconds, retrying (try 3)
    2021-02-27 10:53:39.094: [TUN] [44444] peer(Jkac?/CUs) - Sending
    handshake initiation
    2021-02-27 10:53:44.286: [TUN] [44444] peer(Jkac?/CUs) - Handshake did
    not complete after 5 seconds, retrying (try 4)
    2021-02-27 10:53:44.286: [TUN] [44444] peer(Jkac?/CUs) - Sending
    handshake initiation
    2021-02-27 10:53:49.549: [TUN] [44444] peer(Jkac?/CUs) - Handshake did
    not complete after 5 seconds, retrying (try 5)
    2021-02-27 10:53:49.549: [TUN] [44444] peer(Jkac?/CUs) - Sending
    handshake initiation

    Protokoll Client:
    2021-02-27 10:53:02.793: [TUN] [test-44444] Startup complete
    2021-02-27 10:53:02.836: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake response
    2021-02-27 10:53:23.530: [TUN] [test-44444] peer(A8C8?UUxU) - Retrying
    handshake because we stopped hearing back after 15 seconds
    2021-02-27 10:53:23.530: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake initiation
    2021-02-27 10:53:27.815: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake initiation
    2021-02-27 10:53:27.815: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake response
    2021-02-27 10:53:28.815: [TUN] [test-44444] peer(A8C8?UUxU) -
    Handshake did not complete after 5 seconds, retrying (try 2)
    2021-02-27 10:53:32.982: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake initiation
    2021-02-27 10:53:32.982: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake response
    2021-02-27 10:53:38.283: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake initiation
    2021-02-27 10:53:38.283: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake response
    2021-02-27 10:53:43.475: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake initiation
    2021-02-27 10:53:43.475: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake response
    2021-02-27 10:53:48.738: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake initiation
    2021-02-27 10:53:48.738: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake response
    2021-02-27 10:53:54.066: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake initiation
    2021-02-27 10:53:54.066: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake response
    2021-02-27 10:53:59.148: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake initiation
    2021-02-27 10:53:59.148: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake response
    2021-02-27 10:54:04.459: [TUN] [test-44444] peer(A8C8?UUxU) - Received
    handshake initiation
    2021-02-27 10:54:04.459: [TUN] [test-44444] peer(A8C8?UUxU) - Sending
    handshake response
    2021-02-27 10:54:09.601: [TUN] [test-44444] Device closing

    Apparently, the only message that the server has received from the
    client is the one that was sent to the public address on port 44444.
    After that, the client can no longer send a message - but the other
    way round it can.

    Modifikation

    start a Win10 Sandbox on B.
    install the Wireguard Client? there with the same configuration like
    on B
    deactivate? WG-Client on? B
    the Sandbox could reach A over routing through the running Open-VPN of B
    under these conditions, the wiregiard connection can also be
    established!!

    Protokoll Server:
    2021-02-27 11:46:04.958: [TUN] [44444] Startup complete
    2021-02-27 11:46:05.762: [TUN] [44444] peer(Jkac?/CUs) - Received
    handshake initiation
    2021-02-27 11:46:05.762: [TUN] [44444] peer(Jkac?/CUs) - Sending
    handshake response
    2021-02-27 11:46:05.786: [TUN] [44444] peer(Jkac?/CUs) - Receiving
    keepalive packet
    2021-02-27 11:46:13.757: [MGR] [Wintun] IsPoolMember: Reading pool
    devpkey failed, falling back: Element nicht gefunden. (Code
    0x00000490)
    2021-02-27 11:46:30.795: [TUN] [44444] peer(Jkac?/CUs) - Sending
    keepalive packet
    2021-02-27 11:46:30.812: [TUN] [44444] peer(Jkac?/CUs) - Receiving
    keepalive packet

    Protokoll Client:
    2021-02-27 11:46:05.050: [TUN] [wg-test-sandbox] Startup complete
    2021-02-27 11:46:05.065: [TUN] [wg-test-sandbox] peer(A8C8?UUxU) -
    Received handshake response
    2021-02-27 11:46:05.088: [TUN] [wg-test-sandbox] peer(A8C8?UUxU) -
    Receiving keepalive packet
    2021-02-27 11:46:30.093: [TUN] [wg-test-sandbox] peer(A8C8?UUxU) -
    Sending keepalive packet
    2021-02-27 11:46:30.097: [TUN] [wg-test-sandbox] peer(A8C8?UUxU) -
    Receiving keepalive packet

    Heiko Kendziorra


From mikma.wg at lists.m7n.se  Tue Mar  2 14:31:36 2021
From: mikma.wg at lists.m7n.se (mikma.wg at lists.m7n.se)
Date: Tue, 2 Mar 2021 15:31:36 +0100
Subject: Nested Wireguard tunnels not working on Android and Windows
In-Reply-To: <CAMS0tn2FXkzFHgMgkDwYvD2Fhrxb_PjMNDuV54sL9-ZhTijS7A@mail.gmail.com>
References: <CAMS0tn2Pq65UAVWqjV6mNd1hGqvUxVhVgmR3s2h+kh=XF8jyKA@mail.gmail.com>
 <E8F8664E-3C8A-45B9-B9B8-1A1E2873289B@carmickle.com>
 <65365aa6-cdd0-f9dc-f894-3a040ca596ae@aaronmdjones.net>
 <CAMS0tn0k=7aVstO7Nnn1zZDUypuE2sWidS3uT+04=7rs6+YjGQ@mail.gmail.com>
 <43EFA67E-34E0-4E33-A2FB-EBD42002F1AB@carmickle.com>
 <CAMS0tn2FXkzFHgMgkDwYvD2Fhrxb_PjMNDuV54sL9-ZhTijS7A@mail.gmail.com>
Message-ID: <11abae81-4a87-9016-69a8-e62351a0deba@fox.m7n.se>

On 2021-03-01 21:09, i iordanov wrote:

> Hi Frank,
>
> On Mon, Mar 1, 2021 at 9:42 AM Frank Carmickle <frank at carmickle.com> wrote:
>> Maybe it's a bug and not a feature? It seems to me that you would have no way of setting the MTU on the inner tunnel.
> That's true - other than inefficient packet fragmentation, is there
> anything else that would be an issue?
It's possible to configure the MTU for each route on Linux. (Obviously 
you can't use the extremely simple wg-quick script for this.)
>
>> Is there a reason why you can't try multiple interfaces?
> I cannot bring up more than a single interface on Android. I am not
> sure about interface management on Windows with wg.exe, but
> wireguard.exe certainly does not permit multiple interfaces to be
> brought up.

The WireGuard app on Android also can't use a VPN address as the source 
of WireGuard packets. Only non-VPN addresses are supported.

Which means currently the WireGuard app on Android can't be used for 
nested tunnels.



From nicolai-wireguard at chocolatine.org  Tue Mar  2 17:10:21 2021
From: nicolai-wireguard at chocolatine.org (Nicolai)
Date: Tue, 2 Mar 2021 17:10:21 +0000
Subject: best way for redundancy?
In-Reply-To: <03ff01d70bbb$953d4750$bfb7d5f0$@lindenberg.one>
References: <03ff01d70bbb$953d4750$bfb7d5f0$@lindenberg.one>
Message-ID: <20210302171021.GA65777@chocolatine.org>

On Thu, Feb 25, 2021 at 10:17:06PM +0100, Joachim Lindenberg wrote:

> I do have a wireguard VPN that connects multiple sites. Unfortunately
> some routers are not available all the time, causing network disruption.
> I'd like to improve connectivity via redundancy, i.e. add multiple
> routers that connect the networks.

> What are the options to do that using wireguard? Can I have multiple
> peers with different keys and endpoint but same Allowed IPs? Will
> wireguard select the one available?

In the future I want a similar setup: multiple routers for each network
each seamlessly handling WireGuard when necessary.  I haven't put any
effort into this yet, but my general plan is to use CARP on OpenBSD,
with WireGuard sharing keys.  (I know you want distinct keys, so I
waited to respond until others had a chance.)  Anyway the routers in
City1 would share City1Keys, routers in City2 would share City2Keys,
etc.  When City1Router1 is unavailable, City1Router2 would grab the IP
address and be able to immediately speak WireGuard to the other
locations without anyone noticing.

https://www.openbsd.org/faq/pf/carp.html

Nicolai

From sledz at dresearch-fe.de  Tue Mar  2 21:32:12 2021
From: sledz at dresearch-fe.de (Steffen Sledz)
Date: Tue, 2 Mar 2021 22:32:12 +0100
Subject: Fwd: Problems with Windows client over PulseSecure VPN
In-Reply-To: <1a18b8f5-3c98-24c5-a0ce-90515a8528ae@gmail.com>
References: <9f621ce6-ec3d-0641-c359-756d0ad36f65@gmail.com>
 <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com>
 <CAHmME9ojL5JxWh5Vn_RsBB8baLabhFvotAuSoQ61fJeht=2qEA@mail.gmail.com>
 <2dc629e2-93c9-4ed9-ea57-4318c8b62a73@gmail.com>
 <397bedc7-3913-08bb-a6f3-691d9fab663c@gmail.com>
 <CAN5wt5r9rQpYcCkshBimOARoAxx7T529oUw6RSNnr4q3_y_31g@mail.gmail.com>
 <CAN5wt5ojzay9uEjubrrivd6vZqOGNJ40M25ELzOYTK42zozijQ@mail.gmail.com>
 <1a18b8f5-3c98-24c5-a0ce-90515a8528ae@gmail.com>
Message-ID: <775ac4cf-eeb1-5fa5-29fa-f5ddb8255959@dresearch-fe.de>

On 19.01.21 11:39, Peter Whisker wrote:
> I built Wireguard with the change you made below and ...
> 
> Is there a reason this fix can not be adopted?

According to https://www.wireguard.com/repositories/ should send a properly formatted patch including a Signed-off-by: line using git-send-email to this list.

I suggest to CC the maintainers of the wireguard-windows repo Simon Rozman <simon at rozman.si> and Jason A. Donenfeld <Jason at zx2c4.com>.

Regards,
Steffen


From alexmjoss2413 at gmail.com  Tue Mar  2 23:43:43 2021
From: alexmjoss2413 at gmail.com (Alexander Joss)
Date: Tue, 2 Mar 2021 15:43:43 -0800
Subject: Recommended workaround for resolvconf bug
Message-ID: <CABqpv33QNdT17hZWfuYzc_rGmKgDfbf6iR0JAnp66BXvmfUknA@mail.gmail.com>

Hello list,

I recently moved into a new place and ran into the following issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939904

Any recommendations for workarounds? I tried to create a symlink like
suggested in that thread which seemed to not work and also not exactly
happy about installing another package.

Also, I have no idea why I had no issues with the previous ISP. I no
longer have the old configuration, but I think they were pretty much
identical and didn't have any DNS field setup. Any ideas on why this
became a problem?

Alex

From Jason at zx2c4.com  Wed Mar  3 10:54:23 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 3 Mar 2021 11:54:23 +0100
Subject: Problems with Windows client over PulseSecure VPN
In-Reply-To: <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com>
References: <9f621ce6-ec3d-0641-c359-756d0ad36f65@gmail.com>
 <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com>
Message-ID: <CAHmME9qtPLOTaY3UzyCY1C6guVZXvJjXHeFwT8=94d=Zpjj=Tw@mail.gmail.com>

Hey Peter,

I had a strange idea for how to fix this without requiring
recompilation or removal of that code.

1) Enable DangerousScriptExecution:
https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution

2) Add a PostUp line to your [Interface] section:

PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0

3) Try it and tell me if it works?

Regards,
Jason

From kendziorra at dresearch-fe.de  Wed Mar  3 12:01:16 2021
From: kendziorra at dresearch-fe.de (Heiko Kendziorra)
Date: Wed, 3 Mar 2021 13:01:16 +0100
Subject: Problems with Windows client over PulseSecure VPN
In-Reply-To: <CAHmME9qtPLOTaY3UzyCY1C6guVZXvJjXHeFwT8=94d=Zpjj=Tw@mail.gmail.com>
References: <9f621ce6-ec3d-0641-c359-756d0ad36f65@gmail.com>
 <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com>
 <CAHmME9qtPLOTaY3UzyCY1C6guVZXvJjXHeFwT8=94d=Zpjj=Tw@mail.gmail.com>
Message-ID: <CAA4ESQ25R2RDo9Pr5z+-i8+i-0_d_aGGJb0At+4ba0n1=cv0aQ@mail.gmail.com>

Hi Jakson,
your hint  helped for my Problem:
https://lists.zx2c4.com/pipermail/wireguard/2021-February/006431.html

Thanks a lot!

Am Mi., 3. M?rz 2021 um 11:59 Uhr schrieb Jason A. Donenfeld <Jason at zx2c4.com>:
>
> Hey Peter,
>
> I had a strange idea for how to fix this without requiring
> recompilation or removal of that code.
>
> 1) Enable DangerousScriptExecution:
> https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution
>
> 2) Add a PostUp line to your [Interface] section:
>
> PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0
>
> 3) Try it and tell me if it works?
>
> Regards,
> Jason



-- 
Mit freundlichen Gr??en ? With best regards
Heiko Kendziorra
-----------------------------------------------------------------------------------
Heiko Kendziorra
Softwareentwicklung ? Software Development

DResearch Fahrzeugelektronik GmbH
Tor 2, Aufgang R (R03.020)
Wolfener Stra?e 36
12681 Berlin

Phone: +49 (30) 515 932 - 265
Fax:     +49 (30) 515 932 - 77

Mail:  kendziorra at dresearch-fe.de
Web: www.dresearch-fe.de

General Management  ? Gesch?ftsf?hrung: Dr. Michael Weber, Marc-Oliver Brammann
Amtsgericht Berlin Charlottenburg; HRB 130120; Ust.-IDNr. DE273952058

Kunden Support/Customer support:
Mail: support at dresearch-fe.de
Hotline +49 (30) 515 932 112, Mo. - Do. 10:00 Uhr - 16:00 Uhr,
Freitags von 10:00 bis 13:00 Uhr

From joachim at lindenberg.one  Thu Mar  4 08:58:53 2021
From: joachim at lindenberg.one (Joachim Lindenberg)
Date: Thu, 4 Mar 2021 09:58:53 +0100
Subject: AW: best way for redundancy?
In-Reply-To: <20210302171021.GA65777@chocolatine.org>
References: <03ff01d70bbb$953d4750$bfb7d5f0$@lindenberg.one>
 <20210302171021.GA65777@chocolatine.org>
Message-ID: <005701d710d4$9a398110$ceac8330$@lindenberg.one>

I probably should share some more details about my use case and also why I am hesitating to use OpenBSD/OpnSense etc.
All my VPN-routers are actually virtual machines. One is a virtual private server from a hoster that provides an external static IPv4 address, the others are Ubuntu VMs running on Hyper-V 2019. When I check support of OpenBSD/OpnSense on Hyper-V it looks like this is not really granted, basically works, but... and CARP apparently requires special configuration and cooperation of network drivers. And then I haven?t found good documentation on how to configure CARP with wireguard. 

Thus I tried something else... Until this week, the router of one network was on a mobile machine, which occasionally was really on the road - and the connectivity was of course broken then. There is another host available in the same network that can host a VM, but that host is not running 7*24 for power and noise reasons. That actually suggested a fail over scenario to me. What I configured right now is the following: I "partitioned" that network logically into two groups of VPN-clients. One group is the host and all VMs on the power-saving-host, the other group is the rest. Via DHCP or static routes, each group now uses different routers (part of the respective group) for their respective wireguard tunnel to the other networks. On the other side of the tunnel, network ranges in AllowedIPs are used to address the respective peer (I didn?t dare to have these overlap so far).

That is not really a general high-availability scenario, as essentially I optimized for the expected outages. I am still wondering whether wireguard can support a more general approach without the complexity introduced by CARP. My gut feeling is that the roaming capabilities of wireguard should actually support that very well.

Thanks, Joachim



-----Urspr?ngliche Nachricht-----
Von: WireGuard <wireguard-bounces at lists.zx2c4.com> Im Auftrag von Nicolai
Gesendet: Tuesday, 2 March 2021 18:10
An: wireguard at lists.zx2c4.com
Betreff: Re: best way for redundancy?

On Thu, Feb 25, 2021 at 10:17:06PM +0100, Joachim Lindenberg wrote:

> I do have a wireguard VPN that connects multiple sites. Unfortunately 
> some routers are not available all the time, causing network disruption.
> I'd like to improve connectivity via redundancy, i.e. add multiple 
> routers that connect the networks.

> What are the options to do that using wireguard? Can I have multiple 
> peers with different keys and endpoint but same Allowed IPs? Will 
> wireguard select the one available?

In the future I want a similar setup: multiple routers for each network each seamlessly handling WireGuard when necessary.  I haven't put any effort into this yet, but my general plan is to use CARP on OpenBSD, with WireGuard sharing keys.  (I know you want distinct keys, so I waited to respond until others had a chance.)  Anyway the routers in
City1 would share City1Keys, routers in City2 would share City2Keys, etc.  When City1Router1 is unavailable, City1Router2 would grab the IP address and be able to immediately speak WireGuard to the other locations without anyone noticing.

https://www.openbsd.org/faq/pf/carp.html

Nicolai


From peter.whisker at gmail.com  Thu Mar  4 09:11:12 2021
From: peter.whisker at gmail.com (Peter Whisker)
Date: Thu, 4 Mar 2021 09:11:12 +0000
Subject: Problems with Windows client over PulseSecure VPN
In-Reply-To: <CAHmME9qtPLOTaY3UzyCY1C6guVZXvJjXHeFwT8=94d=Zpjj=Tw@mail.gmail.com>
References: <9f621ce6-ec3d-0641-c359-756d0ad36f65@gmail.com>
 <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com>
 <CAHmME9qtPLOTaY3UzyCY1C6guVZXvJjXHeFwT8=94d=Zpjj=Tw@mail.gmail.com>
Message-ID: <8a1d3115-0726-9dc1-ab84-f98142a908ce@gmail.com>

Hi Jason

Yes, that PostUp line does solve the problem. Thanks! Four tunnels up 
and working with two of them via the PulseSecure VPN. :)

Can I ask why you have the section bind code in there when it seems to 
work fine without it?

Regards

Peter

On 03/03/2021 10:54, Jason A. Donenfeld wrote:
> Hey Peter,
>
> I had a strange idea for how to fix this without requiring
> recompilation or removal of that code.
>
> 1) Enable DangerousScriptExecution:
> https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution
>
> 2) Add a PostUp line to your [Interface] section:
>
> PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0
>
> 3) Try it and tell me if it works?
>
> Regards,
> Jason

From Jason at zx2c4.com  Thu Mar  4 13:07:27 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 4 Mar 2021 06:07:27 -0700
Subject: Problems with Windows client over PulseSecure VPN
In-Reply-To: <8a1d3115-0726-9dc1-ab84-f98142a908ce@gmail.com>
References: <9f621ce6-ec3d-0641-c359-756d0ad36f65@gmail.com>
 <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com>
 <CAHmME9qtPLOTaY3UzyCY1C6guVZXvJjXHeFwT8=94d=Zpjj=Tw@mail.gmail.com>
 <8a1d3115-0726-9dc1-ab84-f98142a908ce@gmail.com>
Message-ID: <CAHmME9qQPZTZ1F0H1txfC+5AODfySMq6HeEqOUoqinMyJES_Yw@mail.gmail.com>

On 3/4/21, Peter Whisker <peter.whisker at gmail.com> wrote:
> Hi Jason
>
> Yes, that PostUp line does solve the problem. Thanks! Four tunnels up
> and working with two of them via the PulseSecure VPN. :)
>
> Can I ask why you have the section bind code in there when it seems to
> work fine without it?

https://lore.kernel.org/wireguard/CAHmME9rXV2_YG3fGMErDeTjfHeNKhDC2cCYA6Kw93n9A328QpQ at mail.gmail.com/

From b.braunger at syseleven.de  Thu Mar  4 18:30:18 2021
From: b.braunger at syseleven.de (Benedikt Braunger)
Date: Thu,  4 Mar 2021 19:30:18 +0100
Subject: [PATCH] added ipv6_dst_lookup_flow define for VZ7 kernels
Message-ID: <20210304183018.42658-1-b.braunger@syseleven.de>

This patch adds an additional check for OpenVZ / Virtuozzo 7 custom
kernels to ensure ipv6_dst_lookup_flow is defined.
It also splits the very long version checking into multiple lines for
better reading.

Signed-off-by: Benedikt Braunger <b.braunger at syseleven.de>
---
Since the error mentioned in "Wireguard DKMS build on OpenVZ 7" still
occures, I searched for a way to check if the module is compiled on 
a VZ kernel. This patch works for me, I tested on Virtuozzo 7 and 
plain CentOS 7. Can compile on both without error and the module is
loadable.
Probably Virtuozzo will backuport ipv6_dst_lookup_flow some day but
they can't (or don't want to) tell me when.
If so one can compare VZVERSION to the current one to ensure the definition
for older verions.

 src/compat/compat.h | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/src/compat/compat.h b/src/compat/compat.h
index 3e8e005..7700e7b 100644
--- a/src/compat/compat.h
+++ b/src/compat/compat.h
@@ -91,7 +91,13 @@
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) && LINUX_VERSION_CODE >= KERNEL_VERSION(3, 16, 83)
 #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup_flow(b, c, d)
-#elif (LINUX_VERSION_CODE < KERNEL_VERSION(5, 4, 5) && LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(5, 3, 18) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0) && !defined(ISUBUNTU1904)) || (!defined(ISRHEL8) && !defined(ISDEBIAN) && !defined(ISUBUNTU1804) && LINUX_VERSION_CODE < KERNEL_VERSION(4, 19, 119) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 15, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 181) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 9, 224) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 5, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 4, 224) && !defined(ISUBUNTU1604) && !defined(ISRHEL7))
+#elif (LINUX_VERSION_CODE < KERNEL_VERSION(5, 4, 5) && LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0))\
+  || (LINUX_VERSION_CODE < KERNEL_VERSION(5, 3, 18) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0) && !defined(ISUBUNTU1904))\
+  || (!defined(ISRHEL8) && !defined(ISDEBIAN) && !defined(ISUBUNTU1804) && LINUX_VERSION_CODE < KERNEL_VERSION(4, 19, 119) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 15, 0))\
+  || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 181) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0))\
+  || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 9, 224) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 5, 0))\
+  || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 4, 224) && !defined(ISUBUNTU1604) && !defined(ISRHEL7))\
+  || (LINUX_VERSION_CODE == KERNEL_VERSION(3, 10, 0) && defined(ISRHEL7) && defined(VZVERSION))
 #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup(a, b, &dst, c) + (void *)0 ?: dst
 #endif
 
-- 
2.25.1


From Jason at zx2c4.com  Fri Mar  5 21:37:21 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 5 Mar 2021 14:37:21 -0700
Subject: [PATCH] wireguard-tools: fix version indicator
In-Reply-To: <20200514093520.10370-1-fe@dev.tdt.de>
References: <20200514093520.10370-1-fe@dev.tdt.de>
Message-ID: <CAHmME9oduEULEHT3kEy_ZNNNTtv8DKztn4XRc7HaLSe3GXKuvw@mail.gmail.com>

Applied, thanks.

From matthias at urlichs.de  Thu Mar  4 08:56:27 2021
From: matthias at urlichs.de (Matthias Urlichs)
Date: Thu, 4 Mar 2021 09:56:27 +0100
Subject: Nested Wireguard tunnels not working on Android and Windows
In-Reply-To: <CAMS0tn2Pq65UAVWqjV6mNd1hGqvUxVhVgmR3s2h+kh=XF8jyKA@mail.gmail.com>
References: <CAMS0tn2Pq65UAVWqjV6mNd1hGqvUxVhVgmR3s2h+kh=XF8jyKA@mail.gmail.com>
Message-ID: <398590d0-70b6-db89-c53c-a9169b0a6fb2@urlichs.de>

On 25.02.21 18:48, i iordanov wrote:
> The "nested" tunnel does not get established.

That's a generic problem. Usually you want to ensure that encrypted 
packets don't themselves go through the tunnel. This is difficult if not 
impossible on Android unless you rooted your device.

Also, you would need a per-route MTU. Linux can do that, but again you 
don't have the privileges on Android.

-- 
-- Matthias Urlichs


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210304/effff038/attachment.sig>

From bradsoto at protonmail.com  Fri Mar  5 20:29:41 2021
From: bradsoto at protonmail.com (Bradley Saulteaux)
Date: Fri, 05 Mar 2021 20:29:41 +0000
Subject: Wireguard Windows ARM64 Build 21327
Message-ID: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>

A quick FYI Wireguard UI stops launching in Windows ARM64 Build 21327. Version 0.3.5 works for me as a temporary workaround. I'm not expecting my configuration to be supported or stressed over in the slightest. I just want to let everyone know about it in case the issue finds its way into official builds.


From kay.diam at gmail.com  Sat Mar  6 09:47:05 2021
From: kay.diam at gmail.com (kayrus)
Date: Sat,  6 Mar 2021 10:47:05 +0100
Subject: [PATCH] FreeBSD default tun name patch
Message-ID: <20210306094705.1037746-1-kay.diam@gmail.com>

This change allows to omit the tun interface name setting in FreeBSD. When name
is not set, kernel automatically picks up the tun name and index.
---
 tun/tun_freebsd.go | 34 ++++++++++++++++++----------------
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/tun/tun_freebsd.go b/tun/tun_freebsd.go
index 12b44da..1883aad 100644
--- a/tun/tun_freebsd.go
+++ b/tun/tun_freebsd.go
@@ -346,22 +346,24 @@ func CreateTUN(name string, mtu int) (Device, error) {
 		return nil, fmt.Errorf("Unable to set nd6 flags for %s: %w", assignedName, errno)
 	}
 
-	// Rename the interface
-	var newnp [unix.IFNAMSIZ]byte
-	copy(newnp[:], name)
-	var ifr ifreq_ptr
-	copy(ifr.Name[:], assignedName)
-	ifr.Data = uintptr(unsafe.Pointer(&newnp[0]))
-	_, _, errno = unix.Syscall(
-		unix.SYS_IOCTL,
-		uintptr(confd),
-		uintptr(unix.SIOCSIFNAME),
-		uintptr(unsafe.Pointer(&ifr)),
-	)
-	if errno != 0 {
-		tunFile.Close()
-		tunDestroy(assignedName)
-		return nil, fmt.Errorf("Failed to rename %s to %s: %w", assignedName, name, errno)
+	if name != "" {
+		// Rename the interface
+		var newnp [unix.IFNAMSIZ]byte
+		copy(newnp[:], name)
+		var ifr ifreq_ptr
+		copy(ifr.Name[:], assignedName)
+		ifr.Data = uintptr(unsafe.Pointer(&newnp[0]))
+		_, _, errno = unix.Syscall(
+			unix.SYS_IOCTL,
+			uintptr(confd),
+			uintptr(unix.SIOCSIFNAME),
+			uintptr(unsafe.Pointer(&ifr)),
+		)
+		if errno != 0 {
+			tunFile.Close()
+			tunDestroy(assignedName)
+			return nil, fmt.Errorf("Failed to rename %s to %s: %w", assignedName, name, errno)
+		}
 	}
 
 	return CreateTUNFromFile(tunFile, mtu)
-- 
2.25.1


From kay.diam at gmail.com  Sat Mar  6 10:00:53 2021
From: kay.diam at gmail.com (kayrus)
Date: Sat,  6 Mar 2021 11:00:53 +0100
Subject: [PATCH] Windows: add convertInterfaceIndexToLUID syscall
Message-ID: <20210306100053.1039719-1-kay.diam@gmail.com>

This change can be used to easily get an access to any interface by name, e.g.

iface, err := net.InterfaceByName(name)
if err ! nil {
	return err
}

luid, err := winipcfg.LUIDFromIndex(uint32(iface.Index))
if err != nil {
	return err
}
---
 tunnel/winipcfg/luid.go              | 11 +++++++++++
 tunnel/winipcfg/winipcfg.go          |  1 +
 tunnel/winipcfg/zwinipcfg_windows.go |  9 +++++++++
 3 files changed, 21 insertions(+)

diff --git a/tunnel/winipcfg/luid.go b/tunnel/winipcfg/luid.go
index efdf1ba4..02ba65b4 100644
--- a/tunnel/winipcfg/luid.go
+++ b/tunnel/winipcfg/luid.go
@@ -63,6 +63,17 @@ func LUIDFromGUID(guid *windows.GUID) (LUID, error) {
 	return luid, nil
 }
 
+// LUIDFromIndex function converts a local index for a network interface to the locally unique identifier (LUID) for the interface.
+// https://docs.microsoft.com/en-us/windows/desktop/api/netioapi/nf-netioapi-convertinterfaceindextoluid
+func LUIDFromIndex(index uint32) (LUID, error) {
+	var luid LUID
+	err := convertInterfaceIndexToLUID(index, &luid)
+	if err != nil {
+		return 0, err
+	}
+	return luid, nil
+}
+
 // IPAddress method returns MibUnicastIPAddressRow struct that matches to provided 'ip' argument. Corresponds to GetUnicastIpAddressEntry
 // (https://docs.microsoft.com/en-us/windows/desktop/api/netioapi/nf-netioapi-getunicastipaddressentry)
 func (luid LUID) IPAddress(ip net.IP) (*MibUnicastIPAddressRow, error) {
diff --git a/tunnel/winipcfg/winipcfg.go b/tunnel/winipcfg/winipcfg.go
index 54040a1c..dd09d3a0 100644
--- a/tunnel/winipcfg/winipcfg.go
+++ b/tunnel/winipcfg/winipcfg.go
@@ -30,6 +30,7 @@ import (
 //sys	getIfTable2Ex(level MibIfEntryLevel, table **mibIfTable2) (ret error) = iphlpapi.GetIfTable2Ex
 //sys	convertInterfaceLUIDToGUID(interfaceLUID *LUID, interfaceGUID *windows.GUID) (ret error) = iphlpapi.ConvertInterfaceLuidToGuid
 //sys	convertInterfaceGUIDToLUID(interfaceGUID *windows.GUID, interfaceLUID *LUID) (ret error) = iphlpapi.ConvertInterfaceGuidToLuid
+//sys	convertInterfaceIndexToLUID(interfaceIndex uint32, interfaceLUID *LUID) (ret error) = iphlpapi.ConvertInterfaceIndexToLuid
 
 // GetAdaptersAddresses function retrieves the addresses associated with the adapters on the local computer.
 // https://docs.microsoft.com/en-us/windows/desktop/api/iphlpapi/nf-iphlpapi-getadaptersaddresses
diff --git a/tunnel/winipcfg/zwinipcfg_windows.go b/tunnel/winipcfg/zwinipcfg_windows.go
index c4bf3b00..ac89fec1 100644
--- a/tunnel/winipcfg/zwinipcfg_windows.go
+++ b/tunnel/winipcfg/zwinipcfg_windows.go
@@ -42,6 +42,7 @@ var (
 
 	procCancelMibChangeNotify2          = modiphlpapi.NewProc("CancelMibChangeNotify2")
 	procConvertInterfaceGuidToLuid      = modiphlpapi.NewProc("ConvertInterfaceGuidToLuid")
+	procConvertInterfaceIndexToLuid     = modiphlpapi.NewProc("ConvertInterfaceIndexToLuid")
 	procConvertInterfaceLuidToGuid      = modiphlpapi.NewProc("ConvertInterfaceLuidToGuid")
 	procCreateAnycastIpAddressEntry     = modiphlpapi.NewProc("CreateAnycastIpAddressEntry")
 	procCreateIpForwardEntry2           = modiphlpapi.NewProc("CreateIpForwardEntry2")
@@ -88,6 +89,14 @@ func convertInterfaceGUIDToLUID(interfaceGUID *windows.GUID, interfaceLUID *LUID
 	return
 }
 
+func convertInterfaceIndexToLUID(interfaceIndex uint32, interfaceLUID *LUID) (ret error) {
+	r0, _, _ := syscall.Syscall(procConvertInterfaceIndexToLuid.Addr(), 2, uintptr(interfaceIndex), uintptr(unsafe.Pointer(interfaceLUID)), 0)
+	if r0 != 0 {
+		ret = syscall.Errno(r0)
+	}
+	return
+}
+
 func convertInterfaceLUIDToGUID(interfaceLUID *LUID, interfaceGUID *windows.GUID) (ret error) {
 	r0, _, _ := syscall.Syscall(procConvertInterfaceLuidToGuid.Addr(), 2, uintptr(unsafe.Pointer(interfaceLUID)), uintptr(unsafe.Pointer(interfaceGUID)), 0)
 	if r0 != 0 {
-- 
2.25.1


From Jason at zx2c4.com  Sun Mar  7 15:49:02 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 7 Mar 2021 08:49:02 -0700
Subject: Wireguard Windows ARM64 Build 21327
In-Reply-To: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>
References: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>
Message-ID: <CAHmME9q5HJ0QJMzqGBPjr-c4YSBcn3=JWjJB6BRAQtvzb02t6A@mail.gmail.com>

Hi Bradley,

Thanks for the report.

> I'm not expecting my configuration to be supported or stressed over in the slightest.

You are in fact very mistaken here. Having everything be broken and
requiring you to resort to out of date versions is very much something
that I'll stress over. Let's fix this.

The first thing I'm wondering is:
- Did v0.3.8 work in builds prior to 21327, or did you never get a
chance to test v0.3.8 on other builds?

Jason

From Jason at zx2c4.com  Sun Mar  7 15:52:17 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 7 Mar 2021 08:52:17 -0700
Subject: [PATCH] Windows: add convertInterfaceIndexToLUID syscall
In-Reply-To: <20210306100053.1039719-1-kay.diam@gmail.com>
References: <20210306100053.1039719-1-kay.diam@gmail.com>
Message-ID: <CAHmME9rkaUbNUmQpOevRSCNbY4tfWWNVAMk9PSMGEi7-D_L0uA@mail.gmail.com>

Can you resubmit your patches with a proper `Signed-off-by:` line,
using `git commit -s --amend`?

From Jason at zx2c4.com  Sun Mar  7 16:10:37 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 7 Mar 2021 09:10:37 -0700
Subject: Maintainer wanted: experienced iOS and macOS dev for WireGuard apps
Message-ID: <CAHmME9rBKDPTZxDHNgGZxoVY0n1Ybm1CDyHiU23eER=nMjB61w@mail.gmail.com>

Hey everyone,

Our macOS and iOS apps are currently the apps most in need of love and
maintenance. So, the project is looking for a dedicated maintainer for
the wireguard-apple git repository. There's probably a decent amount
of work to do up front, clearing out cobwebs, and then after that it's
maintenance as usual. If you've got strong iOS/macOS chops and are
interested, please let me know.

Thanks,
Jason

From kay.diam at gmail.com  Sun Mar  7 16:20:24 2021
From: kay.diam at gmail.com (kayrus)
Date: Sun,  7 Mar 2021 17:20:24 +0100
Subject: [PATCH] Windows: add convertInterfaceIndexToLUID syscall
In-Reply-To: <20210306095820.1039294-1-kay.diam@gmail.com>
References: <20210306095820.1039294-1-kay.diam@gmail.com>
Message-ID: <20210307162024.1153144-1-kay.diam@gmail.com>

This change can be used to easily get an access to any interface by name, e.g.

iface, err := net.InterfaceByName(name)
if err ! nil {
	return err
}

luid, err := winipcfg.LUIDFromIndex(uint32(iface.Index))
if err != nil {
	return err
}

Signed-off-by: kayrus <kay.diam at gmail.com>
---
 tunnel/winipcfg/luid.go              | 11 +++++++++++
 tunnel/winipcfg/winipcfg.go          |  1 +
 tunnel/winipcfg/zwinipcfg_windows.go |  9 +++++++++
 3 files changed, 21 insertions(+)

diff --git a/tunnel/winipcfg/luid.go b/tunnel/winipcfg/luid.go
index efdf1ba4..02ba65b4 100644
--- a/tunnel/winipcfg/luid.go
+++ b/tunnel/winipcfg/luid.go
@@ -63,6 +63,17 @@ func LUIDFromGUID(guid *windows.GUID) (LUID, error) {
 	return luid, nil
 }
 
+// LUIDFromIndex function converts a local index for a network interface to the locally unique identifier (LUID) for the interface.
+// https://docs.microsoft.com/en-us/windows/desktop/api/netioapi/nf-netioapi-convertinterfaceindextoluid
+func LUIDFromIndex(index uint32) (LUID, error) {
+	var luid LUID
+	err := convertInterfaceIndexToLUID(index, &luid)
+	if err != nil {
+		return 0, err
+	}
+	return luid, nil
+}
+
 // IPAddress method returns MibUnicastIPAddressRow struct that matches to provided 'ip' argument. Corresponds to GetUnicastIpAddressEntry
 // (https://docs.microsoft.com/en-us/windows/desktop/api/netioapi/nf-netioapi-getunicastipaddressentry)
 func (luid LUID) IPAddress(ip net.IP) (*MibUnicastIPAddressRow, error) {
diff --git a/tunnel/winipcfg/winipcfg.go b/tunnel/winipcfg/winipcfg.go
index 54040a1c..dd09d3a0 100644
--- a/tunnel/winipcfg/winipcfg.go
+++ b/tunnel/winipcfg/winipcfg.go
@@ -30,6 +30,7 @@ import (
 //sys	getIfTable2Ex(level MibIfEntryLevel, table **mibIfTable2) (ret error) = iphlpapi.GetIfTable2Ex
 //sys	convertInterfaceLUIDToGUID(interfaceLUID *LUID, interfaceGUID *windows.GUID) (ret error) = iphlpapi.ConvertInterfaceLuidToGuid
 //sys	convertInterfaceGUIDToLUID(interfaceGUID *windows.GUID, interfaceLUID *LUID) (ret error) = iphlpapi.ConvertInterfaceGuidToLuid
+//sys	convertInterfaceIndexToLUID(interfaceIndex uint32, interfaceLUID *LUID) (ret error) = iphlpapi.ConvertInterfaceIndexToLuid
 
 // GetAdaptersAddresses function retrieves the addresses associated with the adapters on the local computer.
 // https://docs.microsoft.com/en-us/windows/desktop/api/iphlpapi/nf-iphlpapi-getadaptersaddresses
diff --git a/tunnel/winipcfg/zwinipcfg_windows.go b/tunnel/winipcfg/zwinipcfg_windows.go
index c4bf3b00..ac89fec1 100644
--- a/tunnel/winipcfg/zwinipcfg_windows.go
+++ b/tunnel/winipcfg/zwinipcfg_windows.go
@@ -42,6 +42,7 @@ var (
 
 	procCancelMibChangeNotify2          = modiphlpapi.NewProc("CancelMibChangeNotify2")
 	procConvertInterfaceGuidToLuid      = modiphlpapi.NewProc("ConvertInterfaceGuidToLuid")
+	procConvertInterfaceIndexToLuid     = modiphlpapi.NewProc("ConvertInterfaceIndexToLuid")
 	procConvertInterfaceLuidToGuid      = modiphlpapi.NewProc("ConvertInterfaceLuidToGuid")
 	procCreateAnycastIpAddressEntry     = modiphlpapi.NewProc("CreateAnycastIpAddressEntry")
 	procCreateIpForwardEntry2           = modiphlpapi.NewProc("CreateIpForwardEntry2")
@@ -88,6 +89,14 @@ func convertInterfaceGUIDToLUID(interfaceGUID *windows.GUID, interfaceLUID *LUID
 	return
 }
 
+func convertInterfaceIndexToLUID(interfaceIndex uint32, interfaceLUID *LUID) (ret error) {
+	r0, _, _ := syscall.Syscall(procConvertInterfaceIndexToLuid.Addr(), 2, uintptr(interfaceIndex), uintptr(unsafe.Pointer(interfaceLUID)), 0)
+	if r0 != 0 {
+		ret = syscall.Errno(r0)
+	}
+	return
+}
+
 func convertInterfaceLUIDToGUID(interfaceLUID *LUID, interfaceGUID *windows.GUID) (ret error) {
 	r0, _, _ := syscall.Syscall(procConvertInterfaceLuidToGuid.Addr(), 2, uintptr(unsafe.Pointer(interfaceLUID)), uintptr(unsafe.Pointer(interfaceGUID)), 0)
 	if r0 != 0 {
-- 
2.25.1


From kay.diam at gmail.com  Sun Mar  7 16:21:31 2021
From: kay.diam at gmail.com (kayrus)
Date: Sun,  7 Mar 2021 17:21:31 +0100
Subject: [PATCH] FreeBSD default tun name patch
In-Reply-To: <20210306094705.1037746-1-kay.diam@gmail.com>
References: <20210306094705.1037746-1-kay.diam@gmail.com>
Message-ID: <20210307162131.1153348-1-kay.diam@gmail.com>

This change allows to omit the tun interface name setting in FreeBSD. When name
is not set, kernel automatically picks up the tun name and index.

Signed-off-by: kayrus <kay.diam at gmail.com>
---
 tun/tun_freebsd.go | 34 ++++++++++++++++++----------------
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/tun/tun_freebsd.go b/tun/tun_freebsd.go
index 12b44da..1883aad 100644
--- a/tun/tun_freebsd.go
+++ b/tun/tun_freebsd.go
@@ -346,22 +346,24 @@ func CreateTUN(name string, mtu int) (Device, error) {
 		return nil, fmt.Errorf("Unable to set nd6 flags for %s: %w", assignedName, errno)
 	}
 
-	// Rename the interface
-	var newnp [unix.IFNAMSIZ]byte
-	copy(newnp[:], name)
-	var ifr ifreq_ptr
-	copy(ifr.Name[:], assignedName)
-	ifr.Data = uintptr(unsafe.Pointer(&newnp[0]))
-	_, _, errno = unix.Syscall(
-		unix.SYS_IOCTL,
-		uintptr(confd),
-		uintptr(unix.SIOCSIFNAME),
-		uintptr(unsafe.Pointer(&ifr)),
-	)
-	if errno != 0 {
-		tunFile.Close()
-		tunDestroy(assignedName)
-		return nil, fmt.Errorf("Failed to rename %s to %s: %w", assignedName, name, errno)
+	if name != "" {
+		// Rename the interface
+		var newnp [unix.IFNAMSIZ]byte
+		copy(newnp[:], name)
+		var ifr ifreq_ptr
+		copy(ifr.Name[:], assignedName)
+		ifr.Data = uintptr(unsafe.Pointer(&newnp[0]))
+		_, _, errno = unix.Syscall(
+			unix.SYS_IOCTL,
+			uintptr(confd),
+			uintptr(unix.SIOCSIFNAME),
+			uintptr(unsafe.Pointer(&ifr)),
+		)
+		if errno != 0 {
+			tunFile.Close()
+			tunDestroy(assignedName)
+			return nil, fmt.Errorf("Failed to rename %s to %s: %w", assignedName, name, errno)
+		}
 	}
 
 	return CreateTUNFromFile(tunFile, mtu)
-- 
2.25.1


From Jason at zx2c4.com  Sun Mar  7 16:27:01 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 7 Mar 2021 09:27:01 -0700
Subject: [PATCH] Windows: add convertInterfaceIndexToLUID syscall
In-Reply-To: <20210307162024.1153144-1-kay.diam@gmail.com>
References: <20210306095820.1039294-1-kay.diam@gmail.com>
 <20210307162024.1153144-1-kay.diam@gmail.com>
Message-ID: <CAHmME9qwD5EyUYQbF3ZYDzk5fYU0LdwLJMs+5aeA8SVr0=+mDA@mail.gmail.com>

Applied, thanks:
https://git.zx2c4.com/wireguard-windows/commit/?id=39f3c66fde966b74d093166f7a6504b6d082735f

From Jason at zx2c4.com  Sun Mar  7 16:30:12 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 7 Mar 2021 09:30:12 -0700
Subject: [PATCH] FreeBSD default tun name patch
In-Reply-To: <20210307162131.1153348-1-kay.diam@gmail.com>
References: <20210306094705.1037746-1-kay.diam@gmail.com>
 <20210307162131.1153348-1-kay.diam@gmail.com>
Message-ID: <CAHmME9q2bEt6hzg6Hd3qXPX5Uhs__ZfEq96smUDD8Re07XCapA@mail.gmail.com>

Applied, thanks:
https://git.zx2c4.com/wireguard-go/commit/?id=f4695db51c393f60ed9b8398b95b1f2013ad9b22

From florin at vlaicu.com  Sat Mar  6 19:12:40 2021
From: florin at vlaicu.com (Florin Vlaicu)
Date: Sat, 6 Mar 2021 21:12:40 +0200
Subject: Routing issue
Message-ID: <CAGpywxMdXntKVgEi45zXHGGmnHXeBk4Tiy-c4CkXOF4e9_Oz1w@mail.gmail.com>

I am running a server in a container that uses a macvlan interface to
have a static IP address in my local LAN. Then from my router I DNAT
to that IP address.
If I stop the container and then start it on another host (with the
exact same configuration) existing tunnels will fail, but new ones
will work.
If I just restart the container (or even reboot the host) the existing
tunnels will come back up.
Is there something I can change on the clients to not have to restart
the tunnel?

Thanks,
Florin

From linus at lotz.li  Sun Mar  7 20:57:15 2021
From: linus at lotz.li (Linus Lotz)
Date: Sun, 7 Mar 2021 21:57:15 +0100
Subject: event for peer connection
In-Reply-To: <MUGMypO--3-2@tutanota.com>
References: <MUGMypO--3-2@tutanota.com>
Message-ID: <23c4b81c-dc38-bd9a-6e53-42f83f509c24@lotz.li>

Hi Frank,
I have created a patch for the linux kernel[1], that notifies you about
changes of the endpoint address over netlink. If you could test it and
give some feedback if it works for you that would be great.


[1] https://lore.kernel.org/patchwork/patch/1366219/

Best Regards,
Linus


Am 24.02.21 um 01:11 schrieb frank.mosch at tutanota.com:
> Hello,
> 
> first thank you all for your great work on Wireguard! 
> 
> We would like to switch to wireguard at work but for our setup we need some automatic configuration based on the clients and their IP numbers. Is there a way to get notified when peers connect or send handshake packets? We'd like to avoid polling as the configuration needs to be done rather quickly on a connect for a pleasant user experience.
> A file in /sys or /proc that can be waited on would be best but listening for netlink events would be useful, too. 
> 
> Servus, Frank
> 

From Jason at zx2c4.com  Sun Mar  7 21:49:43 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 7 Mar 2021 14:49:43 -0700
Subject: [PATCH] wireguard: netlink: add multicast notification for peer
 changes
In-Reply-To: <20210109210056.160597-1-linus@lotz.li>
References: <20210109210056.160597-1-linus@lotz.li>
Message-ID: <CAHmME9osYO9O6dikmwR+i44hB_4YqKyc2P3Sre_g9ReHkMJDpQ@mail.gmail.com>

Hey Linus,

Thanks for the patch and sorry for the delay in reviewing it. Seeing
the basic scaffolding for getting netlink notifiers working with
WireGuard is enlightening; it looks surprisingly straightforward.

There are three classes of things that are interesting to receive
notifications for:

1) Things that the admin changes locally. This is akin to the `ip
monitor`, in which you can see various things that other programs (or
the kernel) modify. This seems straightforward and uncontroversial.

2) Authenticated events from peers. This basically amounts to new
sessions being created following a successful handshake. This seems
mostly okay because authenticated actions already have various DoS
protections in place.

3) Unauthenticated events. This would be things like (a) your patch --
a peer's endpoint changes -- or, more interestingly, (b) public keys
of unknown peers trying to handshake.

(b) is interesting because it allows doing database lookups in
userspace, adding the looked up entry, adding it to the interface, and
initiating a handshake in the reverse direction using the endpoint
information. It's partially DoS-protected due to the on-demand cookie
mac2 field.

(a) is also interesting for the use cases you outlined, but much more
perilous, as these are highspeed packets where the outer IP header is
totally unauthenticated. What prevents a man in the middle from doing
something nasty there, causing userspace to be inundated with
expensive calls and filling up netlink socket buffers and so forth?

I wonder if this would be something better belonging to (2) -- getting
an event on an authenticated peer handshake -- and combining that with
the ability to disable roaming (something discussed a few times on
wgml). Alternatively, maybe you have a different idea in mind about
this?

I also don't (yet) know much about the efficiency of multicast netlink
events and what the overhead is if nobody is listening, and questions
like that. So I'd be curious to hear your thoughts on the matter.

Regards,
Jason

From bradsoto at protonmail.com  Mon Mar  8 09:25:40 2021
From: bradsoto at protonmail.com (Bradley Saulteaux)
Date: Mon, 08 Mar 2021 09:25:40 +0000
Subject: Wireguard Windows ARM64 Build 21327
In-Reply-To: <CAHmME9q5HJ0QJMzqGBPjr-c4YSBcn3=JWjJB6BRAQtvzb02t6A@mail.gmail.com>
References: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>
 <CAHmME9q5HJ0QJMzqGBPjr-c4YSBcn3=JWjJB6BRAQtvzb02t6A@mail.gmail.com>
Message-ID: <kvwelbya-mAZJ2wfpt2vqF1O0GE7BwijqjtQjshHnNMooW7y_J8W6BgMKM65sGgZEWZQx7Zr4uejYiDkfL07ckiwZKqt2DR7BNrnJtXUsHs=@protonmail.com>

Hello Jason,

Yes prior to build 21327 the latest version worked.


??????? Original Message ???????
On Sunday, March 7, 2021 8:49 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:

> Hi Bradley,
>
> Thanks for the report.
>
> > I'm not expecting my configuration to be supported or stressed over in the slightest.
>
> You are in fact very mistaken here. Having everything be broken and
> requiring you to resort to out of date versions is very much something
> that I'll stress over. Let's fix this.
>
> The first thing I'm wondering is:
>
> -   Did v0.3.8 work in builds prior to 21327, or did you never get a
>     chance to test v0.3.8 on other builds?
>
>     Jason
>



From Jason at zx2c4.com  Mon Mar  8 15:00:58 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 8 Mar 2021 08:00:58 -0700
Subject: Wireguard Windows ARM64 Build 21327
In-Reply-To: <kvwelbya-mAZJ2wfpt2vqF1O0GE7BwijqjtQjshHnNMooW7y_J8W6BgMKM65sGgZEWZQx7Zr4uejYiDkfL07ckiwZKqt2DR7BNrnJtXUsHs=@protonmail.com>
References: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>
 <CAHmME9q5HJ0QJMzqGBPjr-c4YSBcn3=JWjJB6BRAQtvzb02t6A@mail.gmail.com>
 <kvwelbya-mAZJ2wfpt2vqF1O0GE7BwijqjtQjshHnNMooW7y_J8W6BgMKM65sGgZEWZQx7Zr4uejYiDkfL07ckiwZKqt2DR7BNrnJtXUsHs=@protonmail.com>
Message-ID: <CAHmME9qvexiP9ZFLMJfFEQEnaYHFZkPWmBUBwzdTs7Zov1poCA@mail.gmail.com>

On Mon, Mar 8, 2021 at 2:25 AM Bradley Saulteaux
<bradsoto at protonmail.com> wrote:
>
> Hello Jason,
>
> Yes prior to build 21327 the latest version worked.

Hmm. Anything in the logs from the flawed 0.3.8 launches that might
indicate something?

If you're up for debugging this in real time with me, perhaps we can
jump onto IRC and I can send a few tweaked builds? I'm zx2c4 on
freenode.

Jason

From kevans at freebsd.org  Mon Mar  8 15:02:20 2021
From: kevans at freebsd.org (Kyle Evans)
Date: Mon, 8 Mar 2021 09:02:20 -0600
Subject: [PATCH] FreeBSD default tun name patch
In-Reply-To: <20210306094705.1037746-1-kay.diam@gmail.com>
References: <20210306094705.1037746-1-kay.diam@gmail.com>
Message-ID: <CACNAnaF8zOv0DPS7gSQTACcP9qUBa4PWV+bOeozOPZ1tDk2rvw@mail.gmail.com>

On Sun, Mar 7, 2021 at 9:45 AM kayrus <kay.diam at gmail.com> wrote:
>
> This change allows to omit the tun interface name setting in FreeBSD. When name
> is not set, kernel automatically picks up the tun name and index.
> ---
>  tun/tun_freebsd.go | 34 ++++++++++++++++++----------------
>  1 file changed, 18 insertions(+), 16 deletions(-)
>

Hi,

I'm a little confused by what's going on here -- folks are wanting to
use the assigned name from the tuntap cloner, or is it just a desire
to not require that a new name be specified? The latter seems
incompatible with how the Linux counterpart works, but perhaps Linux
doesn't assign a name/unit when opening /dev/net/tun like we do.

Thanks,

Kyle Evans


> diff --git a/tun/tun_freebsd.go b/tun/tun_freebsd.go
> index 12b44da..1883aad 100644
> --- a/tun/tun_freebsd.go
> +++ b/tun/tun_freebsd.go
> @@ -346,22 +346,24 @@ func CreateTUN(name string, mtu int) (Device, error) {
>                 return nil, fmt.Errorf("Unable to set nd6 flags for %s: %w", assignedName, errno)
>         }
>
> -       // Rename the interface
> -       var newnp [unix.IFNAMSIZ]byte
> -       copy(newnp[:], name)
> -       var ifr ifreq_ptr
> -       copy(ifr.Name[:], assignedName)
> -       ifr.Data = uintptr(unsafe.Pointer(&newnp[0]))
> -       _, _, errno = unix.Syscall(
> -               unix.SYS_IOCTL,
> -               uintptr(confd),
> -               uintptr(unix.SIOCSIFNAME),
> -               uintptr(unsafe.Pointer(&ifr)),
> -       )
> -       if errno != 0 {
> -               tunFile.Close()
> -               tunDestroy(assignedName)
> -               return nil, fmt.Errorf("Failed to rename %s to %s: %w", assignedName, name, errno)
> +       if name != "" {
> +               // Rename the interface
> +               var newnp [unix.IFNAMSIZ]byte
> +               copy(newnp[:], name)
> +               var ifr ifreq_ptr
> +               copy(ifr.Name[:], assignedName)
> +               ifr.Data = uintptr(unsafe.Pointer(&newnp[0]))
> +               _, _, errno = unix.Syscall(
> +                       unix.SYS_IOCTL,
> +                       uintptr(confd),
> +                       uintptr(unix.SIOCSIFNAME),
> +                       uintptr(unsafe.Pointer(&ifr)),
> +               )
> +               if errno != 0 {
> +                       tunFile.Close()
> +                       tunDestroy(assignedName)
> +                       return nil, fmt.Errorf("Failed to rename %s to %s: %w", assignedName, name, errno)
> +               }
>         }
>
>         return CreateTUNFromFile(tunFile, mtu)
> --
> 2.25.1
>

From laura.zelenku at wandera.com  Tue Mar  9 15:02:41 2021
From: laura.zelenku at wandera.com (Laura Zelenku)
Date: Tue, 9 Mar 2021 16:02:41 +0100
Subject: [PATCH] device: revert pipelining UAPI requests
Message-ID: <038632B3-A3F3-4FC6-8242-265A42F89F1F@wandera.com>

Hello devs,
there is an issue when using wg-quick tool and wg tool bellow from wireguard-tools repository (version v1.0.20210223). I?m running: wg-quick up operation with config file in /etc/wireguard/ directory. Get operations are ok. Processed without a problem. But for Set operation the processing will stuck on "buffered.ReadString('\n?)? (in the second run of for loop cycle, after set command is processed in first for loop cycle) because bufio.Scanner will read everything from the socket.
Please revert till proper fix is ready.

thanks
Laura

Signed-off-by: Laura Zelenku <laura.zelenku at wandera.com>
---
 device/uapi.go | 64 +++++++++++++++++++++-----------------------------
 1 file changed, 27 insertions(+), 37 deletions(-)

diff --git a/device/uapi.go b/device/uapi.go
index 659af0a..9fab911 100644
--- a/device/uapi.go
+++ b/device/uapi.go
@@ -414,44 +414,34 @@ func (device *Device) IpcHandle(socket net.Conn) {
                return bufio.NewReadWriter(reader, writer)
        }(socket)
 
-       for {
-               op, err := buffered.ReadString('\n')
-               if err != nil {
-                       return
-               }
+       defer buffered.Flush()
 
-               // handle operation
-               switch op {
-               case "set=1\n":
-                       err = device.IpcSetOperation(buffered.Reader)
-               case "get=1\n":
-                       var nextByte byte
-                       nextByte, err = buffered.ReadByte()
-                       if err != nil {
-                               return
-                       }
-                       if nextByte != '\n' {
-                               err = ipcErrorf(ipc.IpcErrorInvalid, "trailing character in UAPI get: %q", nextByte)
-                               break
-                       }
-                       err = device.IpcGetOperation(buffered.Writer)
-               default:
-                       device.log.Errorf("invalid UAPI operation: %v", op)
-                       return
-               }
+       op, err := buffered.ReadString('\n')
+       if err != nil {
+               return
+       }
 
-               // write status
-               var status *IPCError
-               if err != nil && !errors.As(err, &status) {
-                       // shouldn't happen
-                       status = ipcErrorf(ipc.IpcErrorUnknown, "other UAPI error: %w", err)
-               }
-               if status != nil {
-                       device.log.Errorf("%v", status)
-                       fmt.Fprintf(buffered, "errno=%d\n\n", status.ErrorCode())
-               } else {
-                       fmt.Fprintf(buffered, "errno=0\n\n")
-               }
-               buffered.Flush()
+       // handle operation
+       switch op {
+       case "set=1\n":
+               err = device.IpcSetOperation(buffered.Reader)
+       case "get=1\n":
+               err = device.IpcGetOperation(buffered.Writer)
+       default:
+               device.log.Errorf("invalid UAPI operation: %v", op)
+               return
+       }
+
+       // write status
+       var status *IPCError
+       if err != nil && !errors.As(err, &status) {
+               // shouldn't happen
+               status = ipcErrorf(ipc.IpcErrorUnknown, "other UAPI error: %w", err)
+       }
+       if status != nil {
+               device.log.Errorf("%v", status)
+               fmt.Fprintf(buffered, "errno=%d\n\n", status.ErrorCode())
+       } else {
+               fmt.Fprintf(buffered, "errno=0\n\n")
        }
 }
-- 
2.28.0





-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

From Jason at zx2c4.com  Tue Mar  9 15:09:16 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 9 Mar 2021 08:09:16 -0700
Subject: [PATCH] device: revert pipelining UAPI requests
In-Reply-To: <038632B3-A3F3-4FC6-8242-265A42F89F1F@wandera.com>
References: <038632B3-A3F3-4FC6-8242-265A42F89F1F@wandera.com>
Message-ID: <CAHmME9rakmzN2ndkXchvcRXONjfk4ikJScWCSEYzNR8+1ow03w@mail.gmail.com>

On Tue, Mar 9, 2021 at 8:04 AM Laura Zelenku <laura.zelenku at wandera.com> wrote:
>
> Hello devs,
> there is an issue when using wg-quick tool and wg tool bellow from wireguard-tools repository (version v1.0.20210223). I?m running: wg-quick up operation with config file in /etc/wireguard/ directory. Get operations are ok. Processed without a problem. But for Set operation the processing will stuck on "buffered.ReadString('\n?)? (in the second run of for loop cycle, after set command is processed in first for loop cycle) because bufio.Scanner will read everything from the socket.

I'm unable to reproduce this issue. Can you send a small shell script
that does so?

> Please revert till proper fix is ready.

How hard can a proper fix be? Can't we just commit the actual fix instead?

Jason

From laura.zelenku at wandera.com  Tue Mar  9 16:30:32 2021
From: laura.zelenku at wandera.com (Laura Zelenku)
Date: Tue, 9 Mar 2021 17:30:32 +0100
Subject: [PATCH] device: revert pipelining UAPI requests
In-Reply-To: <CAHmME9rakmzN2ndkXchvcRXONjfk4ikJScWCSEYzNR8+1ow03w@mail.gmail.com>
References: <038632B3-A3F3-4FC6-8242-265A42F89F1F@wandera.com>
 <CAHmME9rakmzN2ndkXchvcRXONjfk4ikJScWCSEYzNR8+1ow03w@mail.gmail.com>
Message-ID: <3A2A1B3E-75FB-4CCA-A7B9-FC7C02B7E9DB@wandera.com>

Hi Jason,
I?m just using ?wg-quick up wg0? command on Linux env with NO kernel module, just userspace implementation.
My config file looks like:
[Interface]
PrivateKey = ?.mEw=
Address = fddd:dddd:1000::1/128
DNS = fddd:dddd::
MTU = 1420
[Peer]
PublicKey = ?..pC0=
AllowedIPs = fd53::/32,fddd:dddd::/128
Endpoint = dev.wandera.com:3005
PersistentKeepalive = 25

In the command output you can see that "wg setconf wg0 /dev/fd/63? stucked and no following commands (set IP address, set MTU, ?) are processed.
The output is:

# wg-quick up wg0
[#] ip link add wg0 type wireguard
RTNETLINK answers: Not supported
[!] Missing WireGuard kernel module. Falling back to slow userspace implementation.
[#] /wireguard/wireguard-go wg0
?????????????????????????????????????????????????????
?                                                   ?
?   Running this software on Linux is unnecessary,  ?
?   because the Linux kernel has built-in first     ?
?   class support for WireGuard, which will be      ?
?   faster, slicker, and better integrated. For     ?
?   information on installing the kernel module,    ?
?   please visit: <https://wireguard.com/install>.  ?
?                                                   ?
?????????????????????????????????????????????????????
DEBUG: (wg0) 2021/03/09 13:11:41 Starting wireguard-go version 0.0.20210212-dirty
DEBUG: (wg0) 2021/03/09 13:11:41 Starting wireguard-go version 0.0.20210212-dirty
DEBUG: (wg0) 2021/03/09 13:11:41 Device started
DEBUG: (wg0) 2021/03/09 13:11:41 UAPI listener started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: decryption worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: encryption worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: decryption worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: handshake worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: encryption worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: handshake worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: handshake worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: encryption worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: decryption worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: decryption worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: encryption worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: handshake worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: TUN reader - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: event worker - started
DEBUG: (wg0) 2021/03/09 13:11:41 Interface up requested
DEBUG: (wg0) 2021/03/09 13:11:41 UDP bind has been updated
DEBUG: (wg0) 2021/03/09 13:11:41 Interface state was Down, requested Up, now Up
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: receive incoming IPv6 - started
[#] wg setconf wg0 /dev/fd/63
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: receive incoming IPv4 - started
DEBUG: (wg0) 2021/03/09 13:11:41 UAPI: Updating private key
DEBUG: (wg0) 2021/03/09 13:11:41 UAPI: Updating listen port
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: receive incoming IPv4 - stopped
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: receive incoming IPv6 - stopped
DEBUG: (wg0) 2021/03/09 13:11:41 UDP bind has been updated
DEBUG: (wg0) 2021/03/09 13:11:41 UAPI: Updating fwmark
DEBUG: (wg0) 2021/03/09 13:11:41 UAPI: Removing all peers
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - Starting...
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - UAPI: Created
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - UAPI: Updating endpoint
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - UAPI: Updating persistent keepalive interval
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - Sending keepalive packet
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - Sending handshake initiation
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - UAPI: Removing all allowedips
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - UAPI: Adding allowedip
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - UAPI: Adding allowedip
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - Routine: sequential receiver - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: receive incoming IPv4 - started
DEBUG: (wg0) 2021/03/09 13:11:41 Routine: receive incoming IPv6 - started
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - Routine: sequential sender - started
DEBUG: (wg0) 2021/03/09 13:11:41 peer(0DIu?qpC0) - Received handshake response
DEBUG: (wg0) 2021/03/09 13:11:42 Interface up requested
DEBUG: (wg0) 2021/03/09 13:11:43 Interface up requested
DEBUG: (wg0) 2021/03/09 13:11:44 Interface up requested
DEBUG: (wg0) 2021/03/09 13:11:45 Interface up requested

As I?m thinking about proper fix I have no idea. The solution would also be to ?return? after first set command (no second loop processing).

Laura


> On 9 Mar 2021, at 16:09, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> On Tue, Mar 9, 2021 at 8:04 AM Laura Zelenku <laura.zelenku at wandera.com> wrote:
>> 
>> Hello devs,
>> there is an issue when using wg-quick tool and wg tool bellow from wireguard-tools repository (version v1.0.20210223). I?m running: wg-quick up operation with config file in /etc/wireguard/ directory. Get operations are ok. Processed without a problem. But for Set operation the processing will stuck on "buffered.ReadString('\n?)? (in the second run of for loop cycle, after set command is processed in first for loop cycle) because bufio.Scanner will read everything from the socket.
> 
> I'm unable to reproduce this issue. Can you send a small shell script
> that does so?
> 
>> Please revert till proper fix is ready.
> 
> How hard can a proper fix be? Can't we just commit the actual fix instead?
> 
> Jason


-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

From Jason at zx2c4.com  Tue Mar  9 16:33:32 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 9 Mar 2021 09:33:32 -0700
Subject: [PATCH] device: revert pipelining UAPI requests
In-Reply-To: <3A2A1B3E-75FB-4CCA-A7B9-FC7C02B7E9DB@wandera.com>
References: <038632B3-A3F3-4FC6-8242-265A42F89F1F@wandera.com>
 <CAHmME9rakmzN2ndkXchvcRXONjfk4ikJScWCSEYzNR8+1ow03w@mail.gmail.com>
 <3A2A1B3E-75FB-4CCA-A7B9-FC7C02B7E9DB@wandera.com>
Message-ID: <CAHmME9qkgbE0E9ApGzMoDeVr289JrrZ42Uyba1hQGNc22VSCMg@mail.gmail.com>

On Tue, Mar 9, 2021 at 9:30 AM Laura Zelenku <laura.zelenku at wandera.com> wrote:
>
> Hi Jason,
> I?m just using ?wg-quick up wg0? command on Linux env with NO kernel module, just userspace implementation.
> My config file looks like:
> [Interface]
> PrivateKey = ?.mEw=

Change your private key. No need to mess with partial exposures.

> In the command output you can see that "wg setconf wg0 /dev/fd/63? stucked and no following commands (set IP address, set MTU, ?) are processed.

What's the output of `wg --version`?

Jason

From kevans at freebsd.org  Tue Mar  9 21:04:51 2021
From: kevans at freebsd.org (Kyle Evans)
Date: Tue, 9 Mar 2021 15:04:51 -0600
Subject: FreeBSD/wireguard-tools
Message-ID: <CACNAnaHUO_GvqQd3BJ2i4Wh45L=0g-LSxJg11G_dEa3UKK6GUw@mail.gmail.com>

Hello!

I'll start off with a slight overview of where we're at from a base
system perspective: in November, an if_wg port from OpenBSD to FreeBSD
landed in our development branch, along with updates to ifconfig(8) to
manage it for the time being. We've committed a number of fixes and
improvements since then[0][1], and we will be shipping that in the
upcoming release of FreeBSD 13.0[2].

The only outstanding issue(s) that I'm aware of (please correct me if
I'm mistaken) are the following:

(1) wireguard-tools doesn't currently support FreeBSD/if_wg, but there
is a  branch (mm/freebsd) that generally does. There are further fixes
to this from the fine folks over at Netgate, see [3]. As a FreeBSD
developer, what can I do to help us move forward together?

(2) There's a preference for using wg(8) for configuration, but we
can't currently include it in base due to licensing. We've got plenty
of precedent for dual-licensed material in base, so if that's a route
that works then I'd like to go ahead and start that discussion.

>From our standpoint, any of: BSD2, BSD3, MIT, ISC licenses can go in
undisputed, choices outside of that require red, yellow, and sometimes
even purple tape.

These are the points that I'd like to start discussing, at least; we
can punt #2 on a little further down the road, though I would like to
have some plan in place to hopefully be able to include it in base for
FreeBSD 13.1 and the integrated version of wg(8) in ports for testing
much sooner.

I appreciate your time and efforts in providing the excellent
WireGuard ecosystem.

Thanks,

Kyle Evans

[0] https://cgit.freebsd.org/src/log/sys/dev/if_wg
[1] https://cgit.freebsd.org/src/log/sbin/ifconfig
[2] https://www.freebsd.org/releases/13.0R/schedule/
[3] https://github.com/pfsense/wireguard-tools/commits/master

From florin at vlaicu.com  Tue Mar  9 07:21:13 2021
From: florin at vlaicu.com (Florin Vlaicu)
Date: Tue, 9 Mar 2021 09:21:13 +0200
Subject: Routing issue
In-Reply-To: <CAOAVeL0mxeXGJXs6idBXyi8ibVvJ2d3qAtEo2Yd2Bby37zQ1RQ@mail.gmail.com>
References: <CAGpywxMdXntKVgEi45zXHGGmnHXeBk4Tiy-c4CkXOF4e9_Oz1w@mail.gmail.com>
 <CAOAVeL0mxeXGJXs6idBXyi8ibVvJ2d3qAtEo2Yd2Bby37zQ1RQ@mail.gmail.com>
Message-ID: <CAGpywxMdNnkx2yZR5y0-P1Czuy1FAWYn-=4EaRDWbE_Rz=60cg@mail.gmail.com>

In the meantime I was able to debug and fix this issue with the help
of the IRC channel.
It turns out the container on the other host had different mac
addresses as soon as I synced them things started working.

Thanks,
Florin

On Tue, Mar 9, 2021 at 8:55 AM Henning Reich <henningreich at gmail.com> wrote:
>
> Have you check time/timezone and wait enough time to clean/rebuild arp caches?
>
> Florin Vlaicu <florin at vlaicu.com> schrieb am So. 7. M?rz 2021 um 18:26:
>>
>> I am running a server in a container that uses a macvlan interface to
>> have a static IP address in my local LAN. Then from my router I DNAT
>> to that IP address.
>> If I stop the container and then start it on another host (with the
>> exact same configuration) existing tunnels will fail, but new ones
>> will work.
>> If I just restart the container (or even reboot the host) the existing
>> tunnels will come back up.
>> Is there something I can change on the clients to not have to restart
>> the tunnel?
>>
>> Thanks,
>> Florin

From spam at bcse.de  Tue Mar  9 12:29:58 2021
From: spam at bcse.de (wp1065151-spam wp1065151-spam)
Date: Tue, 9 Mar 2021 13:29:58 +0100 (CET)
Subject: Question about ACL
Message-ID: <1806565185.3541.1615292999117@ox.hosteurope.de>

Hi.


My Question :
I have two peers configured on my WG Server.

Peer A should grant access to Subnet 10.0.10.0/24
Peer B to 10.0.20.0/24.

In Clientconfig i set 
PEER A
AllowedIPs = 10.255.0.0/24,10.0.10.0/24

PEER B
AllowedIPs = 10.255.0.0/24,10.0.20.0/24


SERVER
[Interface]
Address = 10.9.254.1/24
ListenPort = 55555
PrivateKey = AAAAAAAAAAAAAAAAAAAA=

[Peer]
# PEER A
PublicKey = BBBBBBBBBBBBBBBBBBBB=
AllowedIPs = 10.9.254.100/32

[Peer]
# PEER B
PublicKey = CCCCCCCCCCCCCCCCCCC=
AllowedIPs = 10.9.254.101/32


How can i prevent PEER B from changing his config to :
AllowedIPs = 10.255.0.0/24,10.0.20.0/24,10.0.10.0/24
to get access to 10.0.10.0/24 too ?

If i add allowed IP in servers PEER B config, it will add a route for 10.0.10.0/24 to wg0

So PEER A is not longer be able to access this subnet.

How can i set a ACL that allows Peer A and Peer B only to access configured subnet, outside the client config.

I also could be happen that you would like allow your Friend only to access your Server (.101) and Printer (.150) but you Family the whole subnet.
Therefor Friend get in his peer Config:
AllowedIPs = 10.9.254.0/24,10.0.10.101/32,10.0.10.150/32

Family:
AllowedIPs = 10.9.254.0/24,10.0.10.0/24

How we prevent the Friend to change his config to 10.0.10.0/24 ?

From kexianbin at diyism.com  Tue Mar  9 13:44:56 2021
From: kexianbin at diyism.com (KeXianbin(http://diyism.com))
Date: Tue, 9 Mar 2021 21:44:56 +0800
Subject: Any possibility to run wireguard-go with android vpnservice?
Message-ID: <CAKVinOUJVEyxfT-bOhUe4gZb7yUN_=xwun13pnt+iDZus=LRXQ@mail.gmail.com>

Sorry for bothering,
I'm trying to run wireguard-go with android vpnservice:

first, I started a vpnservice and got the fd integer:

vpnConn=builder.establish();
int fd=vpnConn.getFd();

The key icon showed on the right-top corner of android phone and the
fd  value is 114.

then, I modify tun_linux.go of wireguard-go:
func CreateUnmonitoredTUNFromFD1(fd int) (Device, error) {
    err := unix.SetNonblock(fd, true)
    if err != nil {
        return nil, err
    }
    file := os.NewFile(uintptr(fd), "/dev/tun")
    tun := &NativeTun{
        tunFile: file,
        events:  make(chan Event, 5),
        errors:  make(chan error, 5),
        nopi:    true,
    }
    //name, err := tun.Name()
    if err != nil {
        return nil, err
    }
    return tun, nil
}

and modify main.go :

    tun, err := func() (tun.Device, error) {
        tunFdStr := os.Getenv(ENV_WG_TUN_FD)
        if tunFdStr == "" {
            return tun.CreateTUN(interfaceName, device.DefaultMTU)
        }
        fd, err := strconv.Atoi(tunFdStr);
        return tun.CreateUnmonitoredTUNFromFD1(fd);

But when I run this in android directory /local/data/tmp:

WG_TUN_FD=114 ./wireguard-go wg0

It gives me: Failed to create TUN device: bad file descriptor


It seems that my try is nonsense,
but is there any possibility to run wireguard-go with vpn service
without gomobile jni?


Thanks.

Malcolm Ke

From Jason at zx2c4.com  Tue Mar  9 21:23:22 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 9 Mar 2021 14:23:22 -0700
Subject: FreeBSD/wireguard-tools
In-Reply-To: <CACNAnaHUO_GvqQd3BJ2i4Wh45L=0g-LSxJg11G_dEa3UKK6GUw@mail.gmail.com>
References: <CACNAnaHUO_GvqQd3BJ2i4Wh45L=0g-LSxJg11G_dEa3UKK6GUw@mail.gmail.com>
Message-ID: <CAHmME9pQGWUo=Q0ohXUkXapS7rZ1qbP+GFHkDDOD2hp5VSD+Pw@mail.gmail.com>

Hi Kyle,

Thanks for getting in touch. So far as I can tell, Matt Macy never
finished either the port of wireguard-tools or the port of the actual
kernel module from OpenBSD. I'm CCng Matt Dunwoodie, who has started
working through the kernel module finding issues. There was that awful
error in 25519 (lack of scalar clamping) that somebody emailed me
about a while ago. I don't know if that was ever fixed but I was quite
surprised that got committed. I got the impression from trying to work
with Matt Macy that there wasn't too much interest in collaboration.
Your email is a very welcome change.

I see the path forward for FreeBSD having a functional WireGuard
implementation as something like this:

1. We work out kinks in the kernel module crypto and state machine. I
need to sync with Matt Dunwoodie on his findings there. Maybe we can
send patches ourselves, but maybe it'd be best to just have a
screensharing call where we walk through this together, and after the
call you can code/commit the problems that we identify from
discussion? A similar undertaking has been on my todo list for a
veryverylongtimenow for NetBSD, but that implementation is much, much
further behind, while in contrast I think with FreeBSD we're a lot
closer to things being where they should, and a lot of it will be a
simple matter of syncing the OpenBSD code. So if you're willing to
work with us, I think that's something we can get done together in a
week or faster.

2. We fix/simplify the kernel module's IPC interface to just be a
simple get/set, like every other implementation of WireGuard.

3. We write support for that IPC protocol as "ipc-freebsd.h" in
wireguard-tools. Maybe we'll start with Macy's code, but he never
incorporated the feedback I provided on that, so perhaps you'd like to
start over. Whatever you please there is fine with me.

4. I relicense the tools as MIT. I've previously started on getting
this done, and the only blocker was the embedded libmnl, which is LGPL
and out of my control. But I think there are two reasons why this is
not a real impediment: 1) I've been in touch with the author there,
and I think he'll MIT it if poke again, and 2) that's only for Linux
anyway, so you wouldn't need that file *at all* on FreeBSD.

Does that seem like a good plan? And if so, are you the right contact
with whom to work on it? And what's the FreeBSD release schedule like?
How long do we have to fix this?

Talk soon,
Jason

From Jason at zx2c4.com  Tue Mar  9 21:26:38 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 9 Mar 2021 14:26:38 -0700
Subject: Any possibility to run wireguard-go with android vpnservice?
In-Reply-To: <CAKVinOUJVEyxfT-bOhUe4gZb7yUN_=xwun13pnt+iDZus=LRXQ@mail.gmail.com>
References: <CAKVinOUJVEyxfT-bOhUe4gZb7yUN_=xwun13pnt+iDZus=LRXQ@mail.gmail.com>
Message-ID: <CAHmME9pC=y2_d_z6iyB2ci0O2gKw7WyXnkTxj7AAfwbWLcA7zg@mail.gmail.com>

What you're trying to do has actually already been done and is
available with a nice Java wrapper:

https://git.zx2c4.com/wireguard-android/about/#embedding
https://search.maven.org/artifact/com.wireguard.android/tunnel
https://javadoc.io/doc/com.wireguard.android/tunnel/latest/index.html

This should hopefully save you a bunch of time.

From kexianbin at diyism.com  Wed Mar 10 00:31:27 2021
From: kexianbin at diyism.com (KeXianbin(http://diyism.com))
Date: Wed, 10 Mar 2021 08:31:27 +0800
Subject: Any possibility to run wireguard-go with android vpnservice?
In-Reply-To: <CAHmME9pC=y2_d_z6iyB2ci0O2gKw7WyXnkTxj7AAfwbWLcA7zg@mail.gmail.com>
References: <CAKVinOUJVEyxfT-bOhUe4gZb7yUN_=xwun13pnt+iDZus=LRXQ@mail.gmail.com>
 <CAHmME9pC=y2_d_z6iyB2ci0O2gKw7WyXnkTxj7AAfwbWLcA7zg@mail.gmail.com>
Message-ID: <CAKVinOWSAKSmJZAnx5FazKQqXWnwQkt-AxBH3pR6JrL3SYvi+Q@mail.gmail.com>

Thanks, but I knew android-gui, it used gomobile JNI,
What I'm trying to do is use the same control script (I've integrated
PHP into android)  to manage wireguard process cross multiple
platforms (for example: Android phone and armbian linux TV).
So in my case, command line wireguard accessibility is in first priority.

I saw that someone did it with
tun2socks(https://github.com/jackyflame/Yysk/blob/8ac2b21c1b11eba30205d92e8f96c6d80caaa1dd/app/src/main/java/im/socks/yysk/ssr/SsrTunnel.java#L286):

first Runtime.getRuntime().exec( ... tun2socks  --tunfd
vpnConn.getFd()  --sock-path /local/data/tmp/wg0.sock ...)
then System.sendFd(vpnConn.getFd(), "/local/data/tmp/wg0.sock");

So I'm trying to imitate it with wireguard-go arm64 binary, but I got
no progress

Thanks for your great work

Malcolm Ke

On Wed, Mar 10, 2021 at 5:26 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> What you're trying to do has actually already been done and is
> available with a nice Java wrapper:
>
> https://git.zx2c4.com/wireguard-android/about/#embedding
> https://search.maven.org/artifact/com.wireguard.android/tunnel
> https://javadoc.io/doc/com.wireguard.android/tunnel/latest/index.html
>
> This should hopefully save you a bunch of time.

From Jason at zx2c4.com  Wed Mar 10 00:53:17 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 9 Mar 2021 17:53:17 -0700
Subject: Any possibility to run wireguard-go with android vpnservice?
In-Reply-To: <CAKVinOWSAKSmJZAnx5FazKQqXWnwQkt-AxBH3pR6JrL3SYvi+Q@mail.gmail.com>
References: <CAKVinOUJVEyxfT-bOhUe4gZb7yUN_=xwun13pnt+iDZus=LRXQ@mail.gmail.com>
 <CAHmME9pC=y2_d_z6iyB2ci0O2gKw7WyXnkTxj7AAfwbWLcA7zg@mail.gmail.com>
 <CAKVinOWSAKSmJZAnx5FazKQqXWnwQkt-AxBH3pR6JrL3SYvi+Q@mail.gmail.com>
Message-ID: <CAHmME9rqXMAo8ptzAuL0SL6oVuZk_MGiU969sd0QVYAiN+pAPA@mail.gmail.com>

> So in my case, command line wireguard accessibility is in first priority.

The library I sent you does actually set up a listening socket that
wg(8) can talk to. You should be able to control it from the command
line.

From kevans at freebsd.org  Wed Mar 10 03:14:38 2021
From: kevans at freebsd.org (Kyle Evans)
Date: Tue, 9 Mar 2021 21:14:38 -0600
Subject: FreeBSD/wireguard-tools
In-Reply-To: <CAHmME9pQGWUo=Q0ohXUkXapS7rZ1qbP+GFHkDDOD2hp5VSD+Pw@mail.gmail.com>
References: <CACNAnaHUO_GvqQd3BJ2i4Wh45L=0g-LSxJg11G_dEa3UKK6GUw@mail.gmail.com>
 <CAHmME9pQGWUo=Q0ohXUkXapS7rZ1qbP+GFHkDDOD2hp5VSD+Pw@mail.gmail.com>
Message-ID: <CACNAnaHR+Jmyiaq8UfVp_W=BOA0OZh-_Cn0Lqts+Xj0eN9KY_w@mail.gmail.com>

On Tue, Mar 9, 2021 at 3:23 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Kyle,
>
> Thanks for getting in touch. So far as I can tell, Matt Macy never
> finished either the port of wireguard-tools or the port of the actual
> kernel module from OpenBSD. I'm CCng Matt Dunwoodie, who has started
> working through the kernel module finding issues.

Ah, excellent!

> There was that awful error in 25519 (lack of scalar clamping) that somebody
> emailed me about a while ago. I don't know if that was ever fixed but I was quite
> surprised that got committed.

Indeed, that did get fixed.

> I got the impression from trying to work with Matt Macy that there wasn't too much
> interest in collaboration.  Your email is a very welcome change.

I can't speak much for the historical context here, but I do know that
we as a project
would benefit from collaboration if the end result is being able to
tap into the pre-existing
knowledge pool available here.

> I see the path forward for FreeBSD having a functional WireGuard
> implementation as something like this:
>
> 1. We work out kinks in the kernel module crypto and state machine. I
> need to sync with Matt Dunwoodie on his findings there. Maybe we can
> send patches ourselves, but maybe it'd be best to just have a
> screensharing call where we walk through this together, and after the
> call you can code/commit the problems that we identify from
> discussion? A similar undertaking has been on my todo list for a
> veryverylongtimenow for NetBSD, but that implementation is much, much
> further behind, while in contrast I think with FreeBSD we're a lot
> closer to things being where they should, and a lot of it will be a
> simple matter of syncing the OpenBSD code. So if you're willing to
> work with us, I think that's something we can get done together in a
> week or faster.
>
> 2. We fix/simplify the kernel module's IPC interface to just be a
> simple get/set, like every other implementation of WireGuard.
>
> 3. We write support for that IPC protocol as "ipc-freebsd.h" in
> wireguard-tools. Maybe we'll start with Macy's code, but he never
> incorporated the feedback I provided on that, so perhaps you'd like to
> start over. Whatever you please there is fine with me.
>

We discussed this out-of-band, but to re-iterate that for others that might
have tuned into the thread: I'm interested in maintaining the use of nvlists
for import/export to sidestep around some classes of ABI
concerns/considerations because we maintain two or three major branches
of FreeBSD (if you include the -CURRENT) that fixes/additions could be
backported to if we can manage backward compatibility. We're certainly open
to other possible changes here.

> 4. I relicense the tools as MIT. I've previously started on getting
> this done, and the only blocker was the embedded libmnl, which is LGPL
> and out of my control. But I think there are two reasons why this is
> not a real impediment: 1) I've been in touch with the author there,
> and I think he'll MIT it if poke again, and 2) that's only for Linux
> anyway, so you wouldn't need that file *at all* on FreeBSD.
>

This is excellent, thanks. As you guessed, we can just drop bits from
our vendor import that we won't be building, so no worries here as
long the pertinent parts can be cleanly considered MIT.

> Does that seem like a good plan? And if so, are you the right contact
> with whom to work on it? And what's the FreeBSD release schedule like?
> How long do we have to fix this?
>

This seems like a good plan, and I appreciate it. I'm more than happy
to play the ambassador role here, and hack on whatever I can be useful
with. The final build starts on the 26th and there's a strong
preference (or maybe it's even a hard policy) that there be no changes
between the last RC and the final build.

#1 above is, of course, the most critical step to accomplish prior to
the release. We could conceivably punt #2 to entirely post-release;
the ioctl interface isn't documented, so we could slap warnings in the
pertinent headers and ifconfig/ifwg.c to note that it's unstable and
will change between minor releases.

Punting it down the road a little bit entails a concession that stock
wg(8) will not be usable for FreeBSD 13.0, but we can work with decke@
to conjure up a patch against the port with our existing ipc-freebsd.h
with the limited functionality that it currently entails. I don't
think this is the worst concession we can make as long as it means
that we can focus on making the core functionality rock-solid and as
long as the situation is clearly advertised.

The ports model generally encourages problems with the port/pkg to go
through the port maintainer first, so theoretically decke@ would be
initially fielding any bug reports that arise from the suboptimal
situation in the ~yearish that 13.0 will hold tenure rather than you
seeing complaints from it upstream. The only folks building
wireguard-tools directly from upstream should be those wanting to work
against FreeBSD -CURRENT, but we can slap some __FreeBSD_version
checks in ipc-freebsd.h or somewhere to advise of the situation if
someone tries to use it against revisions that are incompatible with
the new UAPI.

Thanks,

Kyle Evans

From laura.zelenku at wandera.com  Wed Mar 10 12:13:16 2021
From: laura.zelenku at wandera.com (Laura Zelenku)
Date: Wed, 10 Mar 2021 13:13:16 +0100
Subject: [PATCH] device: revert pipelining UAPI requests
In-Reply-To: <CAHmME9qkgbE0E9ApGzMoDeVr289JrrZ42Uyba1hQGNc22VSCMg@mail.gmail.com>
References: <038632B3-A3F3-4FC6-8242-265A42F89F1F@wandera.com>
 <CAHmME9rakmzN2ndkXchvcRXONjfk4ikJScWCSEYzNR8+1ow03w@mail.gmail.com>
 <3A2A1B3E-75FB-4CCA-A7B9-FC7C02B7E9DB@wandera.com>
 <CAHmME9qkgbE0E9ApGzMoDeVr289JrrZ42Uyba1hQGNc22VSCMg@mail.gmail.com>
Message-ID: <B25D7330-7D29-4F61-A097-44F93BDD58F4@wandera.com>

Hello Jason,
I?ve found there was version wireguard-tools v1.0.20200510. Version v1.0.20210223 builded from the source was overriden by package installation in the container :-(
I?ve alligned versions (wireguard-tools v1.0.20210223) and it is working as expected.

I?m sorry for false alert and thank you for your assistance.
Laura

> On 9 Mar 2021, at 17:33, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> On Tue, Mar 9, 2021 at 9:30 AM Laura Zelenku <laura.zelenku at wandera.com> wrote:
>> 
>> Hi Jason,
>> I?m just using ?wg-quick up wg0? command on Linux env with NO kernel module, just userspace implementation.
>> My config file looks like:
>> [Interface]
>> PrivateKey = ?.mEw=
> 
> Change your private key. No need to mess with partial exposures.
> 
>> In the command output you can see that "wg setconf wg0 /dev/fd/63? stucked and no following commands (set IP address, set MTU, ?) are processed.
> 
> What's the output of `wg --version`?
> 
> Jason


-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

From kay.diam at gmail.com  Wed Mar 10 13:36:52 2021
From: kay.diam at gmail.com (kay)
Date: Wed, 10 Mar 2021 14:36:52 +0100
Subject: Windows: wintun MTU is not set
Message-ID: <CANaOhea6dQ6Y5A22B4dO2VEYbk4754rGEi=hw4vfMgvaBo1CAA@mail.gmail.com>

Hi Everyone,

I noticed that the desired MTU is not set on the wintun interface.

I tried to set MTU after I create an interface:

        interfaces, err := winipcfg.GetIPInterfaceTable(windows.AF_UNSPEC)
        if err != nil {
                return err
        }
        for _, iface := range interfaces {
                if iface.InterfaceLUID == luid {
                        log.Printf("Iface: %+#v", iface)
                        iface.NLMTU = 1302
                        err = iface.Set()
                        if err != nil {
                                log.Printf("failed to set MTU: %s", err)
                        }
                }
        }

but it fails with "The parameter is incorrect." for AF_INET. Setting
MTU for AF_INET6 works with no issues.

Any idea how I can set MTU without netsh?

Regards,

From Jason at zx2c4.com  Wed Mar 10 14:02:48 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 10 Mar 2021 07:02:48 -0700
Subject: Windows: wintun MTU is not set
In-Reply-To: <CANaOhea6dQ6Y5A22B4dO2VEYbk4754rGEi=hw4vfMgvaBo1CAA@mail.gmail.com>
References: <CANaOhea6dQ6Y5A22B4dO2VEYbk4754rGEi=hw4vfMgvaBo1CAA@mail.gmail.com>
Message-ID: <CAHmME9o96vy1bo=V+p0C0a5LXuG_6Cw2onoJfTL=5MDg6g=h3A@mail.gmail.com>

Try using the object returned by luid.IPInterface(windows.AF_INET). Or
in your example, use AF_INET instead of AF_UNSPEC.

From kay.diam at gmail.com  Wed Mar 10 14:13:40 2021
From: kay.diam at gmail.com (kay)
Date: Wed, 10 Mar 2021 15:13:40 +0100
Subject: Windows: wintun MTU is not set
In-Reply-To: <CAHmME9o96vy1bo=V+p0C0a5LXuG_6Cw2onoJfTL=5MDg6g=h3A@mail.gmail.com>
References: <CANaOhea6dQ6Y5A22B4dO2VEYbk4754rGEi=hw4vfMgvaBo1CAA@mail.gmail.com>
 <CAHmME9o96vy1bo=V+p0C0a5LXuG_6Cw2onoJfTL=5MDg6g=h3A@mail.gmail.com>
Message-ID: <CANaOheZoKG4m=hMUCbWcsU4PHbKPS5ZtYtqmYvddBPM3-NNv_A@mail.gmail.com>

Thanks. The following code worked for me:

        luid := winipcfg.LUID(tun.LUID())
        iface, err := luid.IPInterface(windows.AF_INET)
        if err != nil {
                return err
        }
        iface.NLMTU = 1302
        err = iface.Set()
        if err != nil {
                return fmt.Errorf("failed to set MTU: %s", err)
        }

On Wed, Mar 10, 2021 at 3:03 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Try using the object returned by luid.IPInterface(windows.AF_INET). Or
> in your example, use AF_INET instead of AF_UNSPEC.

From linus at lotz.li  Sat Mar 13 13:14:34 2021
From: linus at lotz.li (Linus Lotz)
Date: Sat, 13 Mar 2021 14:14:34 +0100
Subject: [PATCH] wireguard: netlink: add multicast notification for peer
 changes
In-Reply-To: <CAHmME9osYO9O6dikmwR+i44hB_4YqKyc2P3Sre_g9ReHkMJDpQ@mail.gmail.com>
References: <20210109210056.160597-1-linus@lotz.li>
 <CAHmME9osYO9O6dikmwR+i44hB_4YqKyc2P3Sre_g9ReHkMJDpQ@mail.gmail.com>
Message-ID: <c97061f5-2d28-0323-c16a-aacacbdc734f@lotz.li>

Hi Jason,> Thanks for the patch and sorry for the delay in reviewing it.
Seeing
> the basic scaffolding for getting netlink notifiers working with
> WireGuard is enlightening; it looks surprisingly straightforward.
Glad to hear that this is a welcome feature.
> 
> There are three classes of things that are interesting to receive
> notifications for:
> 
> 1) Things that the admin changes locally. This is akin to the `ip
> monitor`, in which you can see various things that other programs (or
> the kernel) modify. This seems straightforward and uncontroversial.
The current patch will also trigger for admin changes of the endpoint.
This could obviously be extended to other events as well.
> 
> 2) Authenticated events from peers. This basically amounts to new
> sessions being created following a successful handshake. This seems
> mostly okay because authenticated actions already have various DoS
> protections in place.
> 
> 3) Unauthenticated events. This would be things like (a) your patch --
> a peer's endpoint changes -- or, more interestingly, (b) public keys
> of unknown peers trying to handshake.
I was under the impression that this is an authenticated event. The
function 'wg_socket_set_peer_endpoint' where I hook in the notification
is called from:
- set_peer (changes from netlink, authenticated)
- wg_packet_consume_data_done (which should be authenticated?)
- wg_socket_set_peer_endpoint_from_skb
And wg_socket_set_peer_endpoint_from_skb is in turn called from
wg_receive_handshake_packet where it is called after validating a
handshake initiation and after validating a handshake response. So it
should be authenticated, right?

If the endpoint could be updated without authentication I would be
concerned that an attacker could change the stored endpoint and thus do
a DOS on a tunnel, as he could change the endpoints for both peers by
sending them messages from an invalid endpoint.

> 
> (b) is interesting because it allows doing database lookups in
> userspace, adding the looked up entry, adding it to the interface, and
> initiating a handshake in the reverse direction using the endpoint
> information. It's partially DoS-protected due to the on-demand cookie
> mac2 field.
This is indeed an interesting feature. In this case we might want to
keep the handshake information so that we can complete it if the lookup
is successful. Since this would keep some state for unauthenticated
peers it should probably only be used when explicitly enabled. This
could probably also be used to debug tunnel settings.
> 
> (a) is also interesting for the use cases you outlined, but much more
> perilous, as these are highspeed packets where the outer IP header is
> totally unauthenticated. What prevents a man in the middle from doing
> something nasty there, causing userspace to be inundated with
> expensive calls and filling up netlink socket buffers and so forth?
I was assuming it was authenticated, if not, there should definitely be
some counter measures and it should only be enabled manually.

> 
> I wonder if this would be something better belonging to (2) -- getting
> an event on an authenticated peer handshake -- and combining that with
> the ability to disable roaming (something discussed a few times on
> wgml). Alternatively, maybe you have a different idea in mind about
> this?
If wg_socket_set_peer_endpoint is the only place where the endpoint is
modified it would be relatively simple to implement a flag that disables
roaming. In theory it could also be possible to send a notification, but
 not change the endpoint and only let userspace update it. So an
userspace application could decide if the roaming is allowed or not.
> 
> I also don't (yet) know much about the efficiency of multicast netlink
> events and what the overhead is if nobody is listening, and questions
> like that. So I'd be curious to hear your thoughts on the matter.
I do not know how big the overhead is. I was assuming that a change of
the endpoint address is relatively rare so that the impact should be
negligible (since I assumed that changing the endpoint is authenticated.)

Regards,
Linus

From kay.diam at gmail.com  Sun Mar 14 17:05:11 2021
From: kay.diam at gmail.com (kay)
Date: Sun, 14 Mar 2021 18:05:11 +0100
Subject: A go package for a fine-grained tunnels configuration
Message-ID: <CANaOheZKnxp98ERbCP-jptVtjuDDSc-ZqmWmAnX-vU=SM8D2LQ@mail.gmail.com>

Hi Everyone,

I'm developing a package for the fine-grained tunnel configuration in
different OS's, e.g. IP address, routes, DNSsettings.

It already supports Windows, Linux and FreeBSD (+macOS with an os.Exec
dependency to run networksetup for DNS configuration, need help for a
native support without os.Exec).

I hope you can find it useful and contribute to improving it.

https://github.com/kayrus/tuncfg

Regards,

From samip537 at kapsi.fi  Sun Mar 14 19:01:40 2021
From: samip537 at kapsi.fi (=?UTF-8?Q?Skyler_M=c3=a4ntysaari?=)
Date: Sun, 14 Mar 2021 21:01:40 +0200
Subject: Wireguard on EdgeRouter and using specified VRF and/or routing
 table
In-Reply-To: <8036163fba8a8c7cdea2af0fcac4eb07@kapsi.fi>
References: <8036163fba8a8c7cdea2af0fcac4eb07@kapsi.fi>
Message-ID: <4cb69d55-c577-10d4-2692-f6ebaaba5f1d@kapsi.fi>

Hi,

Could somone help me with this? Last I sent this, I got no replies.

On 27/01/2021 9.45, Skyler M?ntysaari wrote:
> Hi there,
>
> I have a use case where I'm running Bird (BGP daemon) on a EdgeRouter, 
> and then having PTP links via Wireguard for the BGP sessions but I 
> need some help on how to set the wireguard interface to use specified 
> routing table and/or vrf?
>
> I want it to use kernel routing table 1 aswell as specific VRF, and I 
> have set the "route-allowed-ips" to false, as I don't want it to 
> generate it's own routing table.
>
> For reference: Kernel version is 4.9.79.
>
> Best regards,
> Skyler M?ntysaari

From phillip.mcmahon at gmail.com  Sun Mar 14 19:16:21 2021
From: phillip.mcmahon at gmail.com (Phillip McMahon)
Date: Sun, 14 Mar 2021 20:16:21 +0100
Subject: Wireguard on EdgeRouter and using specified VRF and/or routing
 table
In-Reply-To: <4cb69d55-c577-10d4-2692-f6ebaaba5f1d@kapsi.fi>
References: <8036163fba8a8c7cdea2af0fcac4eb07@kapsi.fi>
 <4cb69d55-c577-10d4-2692-f6ebaaba5f1d@kapsi.fi>
Message-ID: <CABtXGiCgmkgZzRejukLDS-RUUR8wxj17JcjDFR+8YatQ_TK4Fg@mail.gmail.com>

I think to get a better response you should post this on the
edgerouter support forums. Mainly as the implementation on edgeOS has
its own nuances, it also sounds like you need some specific routing
advice.

Good luck!

On Sun, 14 Mar 2021 at 20:06, Skyler M?ntysaari <samip537 at kapsi.fi> wrote:
>
> Hi,
>
> Could somone help me with this? Last I sent this, I got no replies.
>
> On 27/01/2021 9.45, Skyler M?ntysaari wrote:
> > Hi there,
> >
> > I have a use case where I'm running Bird (BGP daemon) on a EdgeRouter,
> > and then having PTP links via Wireguard for the BGP sessions but I
> > need some help on how to set the wireguard interface to use specified
> > routing table and/or vrf?
> >
> > I want it to use kernel routing table 1 aswell as specific VRF, and I
> > have set the "route-allowed-ips" to false, as I don't want it to
> > generate it's own routing table.
> >
> > For reference: Kernel version is 4.9.79.
> >
> > Best regards,
> > Skyler M?ntysaari



-- 
Use this contact page to send me encrypted messages and files

https://flowcrypt.com/me/phillipmcmahon

P.S. Drowning in email? Try SaneBox and take back control:
http://sanebox.com/t/old3m. I love it.

From ch at ntrv.dk  Sun Mar 14 19:33:22 2021
From: ch at ntrv.dk (Chriztoffer Hansen)
Date: Sun, 14 Mar 2021 20:33:22 +0100
Subject: Wireguard on EdgeRouter and using specified VRF and/or routing
 table
In-Reply-To: <4cb69d55-c577-10d4-2692-f6ebaaba5f1d@kapsi.fi>
References: <8036163fba8a8c7cdea2af0fcac4eb07@kapsi.fi>
 <4cb69d55-c577-10d4-2692-f6ebaaba5f1d@kapsi.fi>
Message-ID: <CA+cYV6us6diKx8Zg-g5xJnjn3KvvRRRPcOxx0LMV5Wwrhm_wEA@mail.gmail.com>

Wireguard only creates the interface, as far as I know.

you will need to control the VRF the WG interface belongs to with
external tooling not directly related being e.g. wg-quick. (e.g.
systemd or similar)

On Sun, 14 Mar 2021 at 20:01, Skyler M?ntysaari <samip537 at kapsi.fi> wrote:
> Could somone help me with this? Last I sent this, I got no replies.
>
> On 27/01/2021 9.45, Skyler M?ntysaari wrote:
> > I have a use case where I'm running Bird (BGP daemon) on a EdgeRouter,
> > and then having PTP links via Wireguard for the BGP sessions but I
> > need some help on how to set the wireguard interface to use specified
> > routing table and/or vrf?
> >
> > I want it to use kernel routing table 1 aswell as specific VRF, and I
> > have set the "route-allowed-ips" to false, as I don't want it to
> > generate it's own routing table.
> >
> > For reference: Kernel version is 4.9.79.

-- 
Chriztoffer


From web at ka-fi.de  Sun Mar 14 21:07:37 2021
From: web at ka-fi.de (Kai Fischer)
Date: Sun, 14 Mar 2021 21:07:37 +0000
Subject: Kernel module backend on Android 11 ignores custom DNS entry
Message-ID: <eme0e3cfd7-7c4a-48f3-9178-6d1e00e406cb@desktop-o34nbdo>

When using the official Wireguard app on Android 11 with kernel module 
backend , Wireguard ignores the DNS that I set  and routes DNS through 
my phone LTE/Wifi carrier internet DNS.  When using Userspace backend, 
the same config works fine and all DNS queries are routed properly.
Affected kernel module backend version: 1.0.20210219

Anyone noticed this?


From lifeng1519 at gmail.com  Mon Mar 15 07:57:17 2021
From: lifeng1519 at gmail.com (Feng Li)
Date: Mon, 15 Mar 2021 15:57:17 +0800
Subject: Enhance the "AllowedIPs"
Message-ID: <CAEK8JBC6Y7utcom7YCz5AX=bHPOkc6cOdMoMKTC=QhqBQwDp_A@mail.gmail.com>

Hi,

As we know, the AllowedIPs will set the route table. However, if we
want to set the CIDR, but except for some CIDR range, it's not so easy
and out of the box. For example, if I want to route my all traffic,
except the 192.168.0.0/16. I have to calculate the two CIDR
difference:

AllowedIPs =
0.0.0.0/1 + 128.0.0.0/1 - 192.168.0.0/16
=
0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/2,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4,224.0.0.0/3,10.99.0.0/24

Is it possible to be built in Wireguard in the future? I think it's very useful.

The discussion link is here:
https://www.reddit.com/r/WireGuard/comments/m44fi5/enhance_the_allowedips/

Thanks.

From lists at lonnie.abelbeck.com  Mon Mar 15 13:31:12 2021
From: lists at lonnie.abelbeck.com (Lonnie Abelbeck)
Date: Mon, 15 Mar 2021 08:31:12 -0500
Subject: Enhance the "AllowedIPs"
In-Reply-To: <CAEK8JBC6Y7utcom7YCz5AX=bHPOkc6cOdMoMKTC=QhqBQwDp_A@mail.gmail.com>
References: <CAEK8JBC6Y7utcom7YCz5AX=bHPOkc6cOdMoMKTC=QhqBQwDp_A@mail.gmail.com>
Message-ID: <E047ABCC-8C43-4608-A518-B48BF9976B58@lonnie.abelbeck.com>


> On Mar 15, 2021, at 2:57 AM, Feng Li <lifeng1519 at gmail.com> wrote:
> 
> As we know, the AllowedIPs will set the route table. However, if we
> want to set the CIDR, but except for some CIDR range, it's not so easy
> and out of the box. For example, if I want to route my all traffic,
> except the 192.168.0.0/16. I have to calculate the two CIDR
> difference:
> 
> AllowedIPs =
> 0.0.0.0/1 + 128.0.0.0/1 - 192.168.0.0/16
> =
> 0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/2,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4,224.0.0.0/3,10.99.0.0/24

For giggles, I though this might be a clever solution:
--
[Peer]
PublicKey = <remote PublicKey>
Endpoint = remote-vpn:51820
AllowedIPs = 0.0.0.0/0, ::/0

[Peer]
PublicKey = <local PublicKey>
Endpoint = 127.0.0.1:51820
AllowedIPs = 192.168.0.0/16
--

I tested, but wg silently ignores peers to itself.

Lonnie




From Jason at zx2c4.com  Mon Mar 15 14:16:55 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 15 Mar 2021 08:16:55 -0600
Subject: [ANNOUNCE] wireguard-tools v1.0.20210315 released 
Message-ID: <mailman.0.1615817825.269.wireguard@lists.zx2c4.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new version, v1.0.20210315, of wireguard-tools has been tagged in the git
repository, containing various required userspace utilities, such as the
wg(8) and wg-quick(8) commands and documentation.

== Changes ==

  * Makefile: fix version indicator
  
  This lets releases be untar'd into existing git repos without accidentally
  picking up that repo's version number.
  
  * wireguard-tools: const correctness
  * wireguard-tools: drag in headers for prototypes
  
  Cleanups, thanks to verbose warnings on FreeBSD's clang.
  
  * ipc: uniformly ignore preshared keys that are zero
  
  Shouldn't have a practical effect, but fixes correctness on OpenBSD.
  
  * wg-quick: freebsd: add kernel support
  * ipc: freebsd: add initial FreeBSD support
  * wg-quick: freebsd: avoid writing private keys to /tmp
  
  We now support FreeBSD! I'll send an announcement soon with details, but Kyle,
  MattD, and I worked tirelessly to get FreeBSD's kernel implementation up to
  snuff and well supported:
  https://cgit.freebsd.org/src/commit/?id=74ae3f3e33b810248da19004c58b3581cd367843

This release contains commits from: Jason A. Donenfeld, Kyle Evans, and 
Florian Eckert.

As always, the source is available at https://git.zx2c4.com/wireguard-tools/ and
information about the project is available at https://www.wireguard.com/ .

This release is available in compressed tarball form here:
  https://git.zx2c4.com/wireguard-tools/snapshot/wireguard-tools-1.0.20210315.tar.xz
  SHA2-256: af001d5492be6bf58ef0bebe04b446b6f50eb53e1226fab679cc34af40733a22

A PGP signature of that file decompressed is available here:
  https://git.zx2c4.com/wireguard-tools/snapshot/wireguard-tools-1.0.20210315.tar.asc
  Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
  Remember to unxz the tarball before verifying the signature.

If you're a package maintainer, please bump your package version. If you're a
user, the WireGuard team welcomes any and all feedback on this latest version.

Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmBPbE0QHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DruifEADUwp1ZjLW4HBrdefitdFS15AsRtZCYcXWn
PyxaTf/tTjeZMbVgkLh0vSOp+xOxRU6MfdtIvUK7I8dCotmI6ddtS11UjyuSmLjZ
CQA4nmKQoQJ2HeohksCWZDzEFWYKeRsCmzOk39qYFVz2xeAS3YLpuTgRP6jpdgal
o1gDty4A1vNt3nAuRPYMJHx1kBC5+nhvACv25270tf5CLuBvi6+VVHkPsSEl9rOY
XSQtXZrhza/0l82dN8gxkx7D4XmF60NhN8kbaX7V/lVX3ogagP2jSIjkk1xSMbX/
qpPRLod/5IMweA3t2YtQvHnkhBCjSt4jGvFqQJv6bPDKHtNgxYvRYX+gbVF0qBlB
6PZLq1s9fazOD8kCWbY4MV0E+/JbYc6ee8ILI7f2wCVQhKcQiRSiVhYetbenVJzC
7vg1s9sU0i4YpZ/obtNIXuNhfqX0RCa5Q7r3CLpkOOGY7/I05evqakcNNjwtSb8E
W2E8eJ8+bz9Gr5ltqZ56+HA3qvo/tIuqfAYMdITrvEv/TkWMHcaP03qbYNoz4ECG
3zCtJXqXMHNR/mw5vqnKxL8RLoLsdeaR5iU1G2gy9HECzs8iElQijMAgzSJT2MYU
vO8la63vpWa5Fs9YFDQ9CrBPeHNpeDw2mkNYNalLreeMEZW19rGaQK2xser6Jle8
S/BJJp7nfw==
=08Wx
-----END PGP SIGNATURE-----

From Jason at zx2c4.com  Mon Mar 15 14:46:49 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 15 Mar 2021 08:46:49 -0600
Subject: [ANNOUNCE] WireGuard for =?utf-8?Q?FreeBSD?=
 =?utf-8?Q?_in_development_for_13=2Ey_?= =?utf-8?B?4oCT?= and a note of how
 we got here
Message-ID: <YE9zWanlutKYTlKL@zx2c4.com>

Hi everybody,

I?m pleased to announce that WireGuard now runs inside the FreeBSD
kernel, with a driver called if_wg. It has full support of wg(8) and
wg-quick(8) [5], as well as general integration into FreeBSD userland.
Performance should be decent. The implementation in FreeBSD?s main
branch should pretty much work, though it?s something of a so-so work in
progress. To learn what I mean there, read on?

Sometime ago, a popular firewall vendor tasked a developer with writing
a WireGuard implementation for FreeBSD. They didn?t bother reaching out
to the project. That?s okay, I figured, I?ll reach out and see if I can
help and coordinate. What followed over the next year was a series of
poor communications ? messages unanswered, code reviews ignored, that
kind of thing. Usually collaborations I?ve had with others have been
full of excitement, but it just didn?t work out here. In the few
discussions we were able to have, I did get across some key points,
like, ?you?ll save a bunch of time if you use the OpenBSD code as a
starting point.? But mostly it seemed like a stop-and-go effort that the
WireGuard project didn?t have much to do with. Then, at some point,
whatever code laying around got merged into the FreeBSD tree and the
developer tasked with writing it moved on.

Fortunately, two weeks before FreeBSD 13.0 was due to be released,
FreeBSD core developer Kyle Evans emailed the list about integrating
wireguard-tools (wg(8) and such). In the ensuing discussion I mentioned
that we really need to get the actual if_wg kernel implementation up to
snuff. We took the conversation to IRC, and agreed that we should work
on figuring out what to do before the release date. At the same time,
Matt Dunwoodie, who worked on the OpenBSD implementation, also took a
look at what had become of that implementation in FreeBSD. Over the next
week, the three of us dug in and completely reworked the implementation
from top to bottom, each one of us pushing commits and taking passes
through the code to ensure correctness. The result was [6]. It was an
incredible effort. The collaboration was very fast paced and exciting.
Matt and Kyle are terrific programmers and fun to work with too.

The first step was assessing the current state of the code the previous
developer had dumped into the tree. It was not pretty. I imagined
strange Internet voices jeering, ?this is what gives C a bad name!?
There were random sleeps added to ?fix? race conditions, validation
functions that just returned true, catastrophic cryptographic
vulnerabilities, whole parts of the protocol unimplemented, kernel
panics, security bypasses, overflows, random printf statements deep in
crypto code, the most spectacular buffer overflows, and the whole litany
of awful things that go wrong when people aren?t careful when they write
C. Or, more simply, it seems typical of what happens when code ships
that wasn?t meant to. It was essentially an incomplete half-baked
implementation ? nothing close to something anybody would want on a
production machine. Matt had to talk me out of just insisting they pull
the code entirely, and rework it more slowly and carefully for the next
release cycle. And he was right: nobody would have agreed to do that,
and it would only have fostered frustration from folks genuinely
enthusiastic about if_wg. So our one and only option was to iteratively
improve it as fast as we could during the two weeks before release, and
try to make it as simple and close as possible to OpenBSD so that we
could benefit from the previous analysis done there. With that as our
mission, we set out auditing and rewriting code.

One curious thing of note is that there were 40,000 lines of optimized
crypto implementations pulled out of the Linux kernel compat module but
not really wired up correctly, and mangled beyond repair with mazes of
Linux?FreeBSD ifdefs. I wound up replacing this with an 1,800 line file,
crypto.c [1], containing all of the cryptographic primitives needed to
implement WireGuard. Aside from its place in the FreeBSD story, this is
kind of neat in its own right: these are simple, but fast enough,
reference implementations. It?s not deliberately tiny or obfuscated like
TweetNaCl is, yet is still just a single file, and the Curve25519 field
arithmetic in it is formally verified. Maybe other projects will find
use for it. Future releases will hopefully get rid of crypto.c and hook
into FreeBSD?s already existing optimized implementations [4], which
should give a nice performance boost, but given the time crunch, having
something boring, safe, and simple seemed like the way to go.

We reduced the project structure down to four C files ? the
aforementioned crypto.c, two files copied verbatim from OpenBSD ?
wg_noise.c and wg_cookie.c ? and if_wg.c, the actual interface device
driver implementation and protocol logic. The IPC interface was reworked
as well, and wg(8) in the wireguard-tools package grew support for it
(also rewritten from the original attempt). The three of us spent
countless hours across three time zones auditing state machine logic,
running trials,  and generally trying to get this working and workable.
There are now even a few automated tests!

I think we?ve mostly succeeded in producing something that behaves like
WireGuard. The net result certainly isn?t perfect, though ? the Linux
and OpenBSD implementations were long, careful, slow projects by
comparison ? but it is at least a base on which to build and improve
over time. Going forward, I think there?ll be additional systems coding
issues to work out ? locking, lifetimes, races, and that sort of thing.
But now that there?s at least a stable base, developers can work out
remaining issues incrementally.

But perhaps this is a good moment to step back and ask how we got here,
and what WireGuard itself really is.

Traditionally, network protocols are specified in a document of protocol
behaviors. Then different organizations implement that specification.
Then everybody interoperates and all goes well. In practice, it often
doesn?t go well (see IPsec woes), but this at least has been the
traditional way of doing this on the Internet, and in some ways it
works.

But that is not the approach taken by the WireGuard project. In
contrast, WireGuard is both a protocol and a set of implementations,
implemented with a particular set of security and safety techniques.
That?s a radical departure from the traditional model, and one surely to
raise some grumbles amongst graybeards. But I believe this is a
necessary and beneficial quality for having the types of high assurance
software that is needed for core Internet security infrastructure. When
you use WireGuard, you?re not just using some protocol that is capable
of producing packets that are legible by others. You?re also using an
implementation that?s been designed to avoid security pitfalls, and that
provides interfaces for using it that mitigate footguns. In that way,
the WireGuard project is more expansive than a mere protocol project or
a mere software project or a mere cryptography project or a mere
specification project or a mere interface project. It combines all of
those things into a single unified approach. (For this same reason, the
original WireGuard paper [2] has been difficult for folks to categorize.
Is this a systems paper? A networking paper? A crypto paper?)

Because of that, I think this was an understandable predicament. After
all, why shouldn?t a company be able to task a developer with writing
some ring-0 WireGuard code in C? And why does it matter to me whether
the code is garbage if it can at least produce protocol packets? The
reason is that the WireGuard project?s mission is wider than that. We
deeply care about code quality and implementation particulars.

While we now have the FreeBSD code in a maintainable state, there are
other projects too that could use some attention from us. Looking
forward, for example, we hope to be able to lend a hand similarly to the
NetBSD developers soon to help them finish their implementation; this is
long overdue on my part, and I owe them some time and energy there. And
I hope that others don?t hesitate to email the list asking for
collaboration. This kind of thing is, of course, one of the reasons that
the project as an organization exists.

To return to the primary announcement, I had originally hoped to say
that this would be shipping for 13.0, and have some instructions for
setup there, but unfortunately, and contrary to our plans, it looks
exceedingly likely that given the grave issues we found in the existing
code, they?ll in the end just disable the module from the release, and
revisit for 13.1, rather than merging our fixes a few short days before
the release. That?s a bit of a bummer, given how hard we worked to get
things done in the time crunch, but it?s also probably a very wise
decision that takes some courage to make, and this will give us more
time to really get this rock solid for 13.1.

As well, hopefully we?ll have backport modules for the 13.0 and 12.y
release, making it as available as possible. Kyle or I will update the
list when  we?ve got a standalone backport module ready, with
instructions, as well as updating [3] per usual. There?s also ongoing
work to integrate WireGuard interface setup into rc, and hopefully that
will land during the the next release window, as well as the
aforementioned improvements to optimized crypto and systems issues.

Enjoy,
Jason

[1] https://cgit.freebsd.org/src/tree/sys/dev/if_wg/crypto.c?id=74ae3f3e33b810248da19004c58b3581cd367843
[2] https://www.wireguard.com/papers/wireguard.pdf
[3] https://www.wireguard.com/install/
[4] https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057076.html
[5] https://lists.zx2c4.com/pipermail/wireguard/2021-March/006493.html	
[6] https://cgit.freebsd.org/src/commit/?id=74ae3f3e33b810248da19004c58b3581cd367843

From me at aaronmdjones.net  Mon Mar 15 14:57:38 2021
From: me at aaronmdjones.net (Aaron Jones)
Date: Mon, 15 Mar 2021 14:57:38 +0000
Subject: Enhance the "AllowedIPs"
In-Reply-To: <E047ABCC-8C43-4608-A518-B48BF9976B58@lonnie.abelbeck.com>
References: <CAEK8JBC6Y7utcom7YCz5AX=bHPOkc6cOdMoMKTC=QhqBQwDp_A@mail.gmail.com>
 <E047ABCC-8C43-4608-A518-B48BF9976B58@lonnie.abelbeck.com>
Message-ID: <ec03842a-ab61-69dc-61f6-5c5a042679e2@aaronmdjones.net>

On 15/03/2021 13:31, Lonnie Abelbeck wrote:
> For giggles, I though this might be a clever solution:
> --
> [Peer]
> PublicKey = <remote PublicKey>
> Endpoint = remote-vpn:51820
> AllowedIPs = 0.0.0.0/0, ::/0
> 
> [Peer]
> PublicKey = <local PublicKey>
> Endpoint = 127.0.0.1:51820
> AllowedIPs = 192.168.0.0/16
> --
> 
> I tested, but wg silently ignores peers to itself.
> Lonnie

Indeed; but nothing prevents you from terminating it with a different
local WireGuard interface with a different private key.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210315/1a4d97f2/attachment.sig>

From reto at labrat.space  Mon Mar 15 19:49:19 2021
From: reto at labrat.space (Reto)
Date: Mon, 15 Mar 2021 20:49:19 +0100
Subject: [ANNOUNCE] WireGuard for FreeBSD in development =?utf-8?Q?for?=
 =?utf-8?B?IDEzLnkg4oCT?= and a note of how we got here
In-Reply-To: <YE9zWanlutKYTlKL@zx2c4.com>
References: <YE9zWanlutKYTlKL@zx2c4.com>
Message-ID: <20210315194919.mj6cnnzcxhsoa7ae@feather.localdomain>

That's awesome!

Thanks a lot for your hard work and dedication on wireguard.
I really appreciate what you do including your willingness to work with non
Linux OSes.

Cheers,
Reto

From daniel.hope at smartalock.com  Mon Mar 15 16:55:36 2021
From: daniel.hope at smartalock.com (Daniel Hope)
Date: Mon, 15 Mar 2021 16:55:36 +0000
Subject: WireGuard Implementation for LwIP Stack
Message-ID: <7E828597-A5E0-4E54-B2C4-F1E83F25CD71@smartalock.com>

I have developed a WireGuard implementation for an embedded project we are working on that uses LwIP as the IP stack. The implementation has been released here: https://github.com/smartalock/wireguard-lwip 

LwIP is an open source TCP/IP stack that is used mainly in embedded systems, often those with very tight memory requirements for code/data size, and normally not running Linux / BSD or even any operating system at all.

The project contains a pure C, malloc free implementation of the WireGuard protocol, some glue in the form of a lwIP netif implementation and some crypto elements that end users will probably want to optimise for their specific embedded platform. I wish I?d seen the single file crypto.c file that Jason just announced in the FreeBSD code as that would have been useful? although the x25519 probably would still use too much stack for us.

In terms of size we can run a couple of WireGuard peers as well as our main application on an STM32F10x board that has just 64K RAM - the goal here being secure connectivity rather than raw packet throughput.

I?d welcome any feedback to improve the code!

In terms of other ideas I think this code could be adapted to run as a static C library to link against to enable per-application WireGuard support. Whilst there are other methods that already exist to do this - e.g. containerisation, or via the library here: https://git.zx2c4.com/wireguard-tools/tree/contrib/embeddable-wg-library/, etc these tend to require either operating system tunnel/network interface support or Linux in particular.

Daniel

From tim at startuptim.com  Sun Mar 14 23:51:45 2021
From: tim at startuptim.com (Tim)
Date: Sun, 14 Mar 2021 18:51:45 -0500
Subject: Wireguard Windows client/exe - disable creation of routes
Message-ID: <CABmZ64w1j-5py4xc-JPUU4wz52w3+zpYptoDxENifzeKk5HxRg@mail.gmail.com>

Does anybody know how one can use the Wireguard Windows
client/executables to establish a connection but not have the
client/executables modify the Windows routing tables.  Functionality
similar to the "Table = off" in the linux WG but using the Wireguard
Windows executables (wg.exe/wireguard.exe)?

My goal is to use the existing executables but to handle route
creation on my own.

I've tried "Table = off" but it does not work.  Nor does a cursory
examination of the source code.  Though this seems to be something
basic, so I imagine I am missing how to do it.

Any idea?

Thanks in advance for your help!

From Jason at zx2c4.com  Tue Mar 16 01:18:19 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 15 Mar 2021 19:18:19 -0600
Subject: [ANNOUNCE] WireGuard for =?utf-8?Q?Fre?=
 =?utf-8?Q?eBSD_in_development_for_13=2Ey_?= =?utf-8?B?4oCT?= and a note of
 how we got here
In-Reply-To: <YE9zWanlutKYTlKL@zx2c4.com>
References: <YE9zWanlutKYTlKL@zx2c4.com>
Message-ID: <YFAHW1lfTinihSGj@zx2c4.com>

Hi Scott,

It's certainly disappointing to receive your email like that. I see that
you're really upset, and I think we have a shared interest in
deescalating this. You've mentioned the desire to talk about this in
public, so I'm responding in the announcement thread to you, as this
seems like the appropriate venue for discussion.  I've also CC'd the
FreeBSD Security Officer. I've responded to your email and its threats
in line mailing-list style below:

On Mon, Mar 15, 2021 at 6:08 PM Scott Long <scottl at netgate.com> wrote:
> What you and Kyle did was tell the world that there are a number of
> zero-day exploits in the code. ?You gave us no details until after the
> fact, gave us no time to mitigate, correct, and publish before your
> announcement and Kyle's code drop, and used the opportunity to
> bash the code, and by extension us, for your own self-gain.

I have no idea how you possibly have arrived at this here. FreeBSD 13 is
currently at RC2 or RC3, if I recall correctly. Our whole motivation for
working on this so tirelessly and with so much energy and devotion over
the week was to get things fixed up before 13 was actually released. I
dropped everything else I was working on to focus on this. I'm actually
with my folks in Colorado and should be spending more time with them but
the idea of FreeBSD 13 shipping with all those bugs seemed like a really
important thing to address.

Here's what we did, step by step:

1. We made a clone of the freebsd git repo where we could all push
   changes to master, to git.zx2c4.com like everything else.

2. We took turns taking big passes at the codebase, reading it, auditing
   it, fixing things. We did a lot of syncing and comparison with the
   OpenBSD code base. For example, in one step, we reordered the functions
   to match the flow of OpenBSD so we could see it more easily side by
   side.

3. We kept pushing commits like this in that manner.

4. We didn't know where we'd end up, but after a few days of this, the
   number of changes we had accumulated and fishy business we had observed
   was massive.

5. When we thought we reached a good resting point -- and when it became
   clear that our rapid fire changes were becoming too numerous -- we
   squashed that down to a summary commit, and Kyle committed it.

6. Seeing that the crypto needed to be re-accelerated, I published a
   call for help here --
   https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057076.html

7. I published wireguard-tools with the improved wg(8) command here --
   https://lists.zx2c4.com/pipermail/wireguard/2021-March/006493.html

8. I sent a summary of everything to the mailing list here --
   https://lists.zx2c4.com/pipermail/wireguard/2021-March/006494.html

I also made sure to email a FreeBSD Security Officer, Colin, to keep
him posted about the state of this, so he was kept apprised.

Again, the whole idea was: two weeks until release! If I suggest the
code is just disabled, people will be really upset, so instead we'll try
to fix as much as fast as possible before the release. And actually,
really focused sprints like that are fun and stimulating. We were all
really enjoying writing code until the torrents of anger started coming
from you about our efforts. (And I also learned that this isn't the
first time you guys tried to intimidate an open source project -- see
this summary of the opnSense defamatory website Netgate created --
https://opnsense.org/opnsense-com/ .)

And in the process, too, I've tried to be in contact with you and Jim
and let you know what our intentions are and to diffuse tensions. I
spent time on a video call trying to describe to you some of the
security things we found, in case it wasn't possible for you to use the
new code right away. I've also made it abundantly clear to you how much
I want to work WITH Netgate. When that Reddit thread cropped up, I
offered to you multiple times to send a message to it telling people
that we've spoken and it looks like you have a good plan and every
things going to be okay, but you didn't respond to my offer.

On Mon, Mar 15, 2021 at 6:08 PM Scott Long <scottl at netgate.com> wrote:
> None
> of these actions reflect good-faith collaboration, and your statements
> that you think that our work is "really cool" ring hollow. ?Maybe you
> and Kyle are really naive and thought that this was how people
> normally collaborate in the security and business worlds, and that
> everyone would rush to praise you and shower you with contracts
> and funding. ?And hey, maybe that?ll happen, you certainly have
> made a splash. ?That of course, comes at our expense, and it?s
> likely to be a pretty damaging one. ?Now with the Ars article, I?m
> starting to wonder if this was a coordinated smear campaign.
> Normally we don?t get this kind of attention. ?It?s going to be painful
> to navigate our way out.

I'm not sure how to address these types of... theories. I certainly AM
acting in good faith. I can't possibly see how it benefits anybody to
have WireGuard and Netgate at odds with one another. You guys make a
neat product based on open source software, and I think it's great
you're planning to add WireGuard to it. My interest is in making sure
the underlying operating system -- FreeBSD 13 -- does that well.  (Or, I
think you mentioned to me this morning that you're actually planning to
base it on FreeBSD 12 for some time, but same idea for the backport
you're working on, I guess.)

And there's no "smear campaign" -- that's outrageous. I have no idea how
that would help anybody at all. I should point out, again to you, how
grateful I am that Netgate got the initial work on this started. Had you
guys not gotten if_wg rolling, it's not clear to me that it'd exist in
the first place.

>From your end, it's very disappointing that you're (below) planning to
attack security researchers and kernel programmers who took the time to
rewrite code to make it better, hustling to get it in before FreeBSD 13
is released.

On Mon, Mar 15, 2021 at 6:08 PM Scott Long <scottl at netgate.com> wrote:
> I?ll be writing an article tonight outlining the mistakes that we made
> and what we will be doing to correct it. ?I?ll also be highlighting that
> this incident has been a textbook example of the wrong way for
> people to collaborate in the security community, and that extreme
> caution should be taken in any future dealings with you. ?Your
> actions are self serving and in bad faith, and your words are
> hollow and untrustworthy. ?I don?t care if you disagree or don?t see
> it this way, this is the effect that you?ve had.

It makes sense to communicate with your customers about things with your
upcoming products if you feel it's necessary. But threatening that
you're going to highlight "that extreme caution should be taken in any
future dealings with you" sounds to me like a threat of some intense
slander. And again, attacking security researchers and kernel
programmers who took time to rewrite code to make it better before a
release deadline...  That's ...wow. I wish you would not go on the
attack like that.

Instead, it seems like we can both be glad that we're on the path to
having better code! And that there's a team of people volunteering to do
this and enjoying writing that code. We're all working together to make
things better. We worked really super hard on fixing up this code base.
It was a LOT of work. And I would like to keep working on it and feeling
good about it.

So I'm just disappointed that somehow this has devolved for you into
making threats like that.

On Mon, Mar 15, 2021 at 6:08 PM Scott Long <scottl at netgate.com> wrote:
> I?ve also spoken with the FreeBSD Security Officer, and we?ve
> agreed that wireguard will be removed from all branches of FreeBSD
> until further notice. ?I?ve also informed Kyle of this. ?I do not support
> its reintroduction into FreeBSD, whether in the src tree or in the
> ports tree, at this time. ?As for pfSense, we are conducting an
> audit and will decide on the best course of action for our customers
> and our company.

I actually think that's a great idea. I was under the impression
initially that removing it would be a total non-starter and would just
make people upset, hence this hurried mad dash to turn things around.
But having an opportunity to take it out of tree and develop it slowly
and carefully, like we did for Linux and OpenBSD, sounds a lot better.
This also meshes well with what we had planned to do, which I mentioned
in the announcement email this morning -- have this available as an out
of tree module that people can try out. Then, after we've got it really
solid, reintroduce it in the normal FreeBSD ways of doing that. (I'm not
so familiar with that latter process, but I trust that Kyle & folks know
that part well.)

On Mon, Mar 15, 2021 at 6:08 PM Scott Long <scottl at netgate.com> wrote:
>
> Scott

So, that's where we are. You're upset and making threats to slander
security researchers and kernel programmers. That's really
disappointing. All I can do is ask you: please don't? We have much more
to gain by supporting each other than being in conflict. I just want to
make sure FreeBSD 13 (or 14) gets a great WireGuard implementation. And
you want to make sure your customers get great products. I see no reason
why these are conflicting goals.

I hope this can deescalate, and we can work together on this. I'm
confident that our goals are ultimately aligned very well.

Regards,
Jason

From wireguard at spam-free.eu  Tue Mar 16 11:33:54 2021
From: wireguard at spam-free.eu (Chris)
Date: Tue, 16 Mar 2021 12:33:54 +0100
Subject: Enhance the "AllowedIPs"
In-Reply-To: <CAEK8JBC6Y7utcom7YCz5AX=bHPOkc6cOdMoMKTC=QhqBQwDp_A@mail.gmail.com>
References: <CAEK8JBC6Y7utcom7YCz5AX=bHPOkc6cOdMoMKTC=QhqBQwDp_A@mail.gmail.com>
Message-ID: <b7fb35f2-5d82-b4d6-5add-e18f5d032010@spam-free.eu>

Just in case:
I guess you have already thought about using the post script to add a separate 
route to 192.160.0.0/16 using the original path with a lower metric.

On 15/03/2021 08:57, Feng Li wrote:
> Hi,
>
> As we know, the AllowedIPs will set the route table. However, if we
> want to set the CIDR, but except for some CIDR range, it's not so easy
> and out of the box. For example, if I want to route my all traffic,
> except the 192.168.0.0/16. I have to calculate the two CIDR
> difference:
>
> AllowedIPs =
> 0.0.0.0/1 + 128.0.0.0/1 - 192.168.0.0/16
> =
> 0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/2,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4,224.0.0.0/3,10.99.0.0/24
>
> Is it possible to be built in Wireguard in the future? I think it's very useful.
>
> The discussion link is here:
> https://www.reddit.com/r/WireGuard/comments/m44fi5/enhance_the_allowedips/
>
> Thanks.


From timstartuptim at gmail.com  Mon Mar 15 20:49:36 2021
From: timstartuptim at gmail.com (Tim)
Date: Mon, 15 Mar 2021 15:49:36 -0500
Subject: Wireguard Windows client/exe - disable creation of routes
Message-ID: <CABmZ64yKVBO0jz68qOeQfZ+cxwn0JcfOy9=pKNP1AjLDDUAg9Q@mail.gmail.com>

Does anybody know how one can use the Wireguard Windows
client/executables to establish a connection but not have the
client/executables modify the Windows routing tables.  Functionality
similar to the "Table = off" in the linux WG but using the Wireguard
Windows executables (wg.exe/wireguard.exe)?

My goal is to use the existing executables but to handle route
creation on my own.

I've tried "Table = off" but it does not work.  Nor does a cursory
examination of the source code.  Though this seems to be something
basic, so I imagine I am missing how to do it.

Any idea?

Thanks in advance for your help!

From leptonyu at gmail.com  Mon Mar 15 22:52:36 2021
From: leptonyu at gmail.com (Daniel Yu)
Date: Tue, 16 Mar 2021 06:52:36 +0800
Subject: Is iOS testlight available?
Message-ID: <A7D1188B-A61E-4167-8BBF-A06F2AF3F1F8@gmail.com>

Hi,
   My ios version is outdated with TestFlight.

Thanks

From laura.zelenku at wandera.com  Tue Mar 16 14:03:09 2021
From: laura.zelenku at wandera.com (Laura Zelenku)
Date: Tue, 16 Mar 2021 15:03:09 +0100
Subject: Handshake state collision between parralel RoutineHandshake
 threads
In-Reply-To: <92B58443-8904-417B-A866-7BD2C6240B42@wandera.com>
References: <27D86318-AED9-49EC-94EE-1FFC806533DC@wandera.com>
 <CAHmME9oOKvMqvSw_CrjhiWU+R60AEVxLYzoaC8W7F7D5vWgWvA@mail.gmail.com>
 <92B58443-8904-417B-A866-7BD2C6240B42@wandera.com>
Message-ID: <6B92ECA6-AEC9-42F2-AB98-013CBB70691C@wandera.com>

Still struggling with this issue. Running RoutineHandshake in single instance will help. Remember there is shared resource ?peer.handshake.state?. Even the resource is per peer there are two directions (upstream/downstream) that can fight for this resource and write it?s own value.

Index: device/receive.go
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- device/receive.go	(revision 5f0c8b942d93be6ac36a156c0ba44c86c3698f91)
+++ device/receive.go	(date 1615902577604)
@@ -10,6 +10,7 @@
 	"encoding/binary"
 	"errors"
 	"net"
+	"runtime"
 	"sync"
 	"sync/atomic"
 	"time"
@@ -239,7 +240,9 @@
 func (device *Device) RoutineHandshake() {
 	defer func() {
 		device.log.Verbosef("Routine: handshake worker - stopped")
-		device.queue.encryption.wg.Done()
+		for i := 0; i < runtime.NumCPU(); i++ {
+			device.queue.encryption.wg.Done()
+		}
 	}()
 	device.log.Verbosef("Routine: handshake worker - started")
 
Index: device/device.go
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- device/device.go	(revision 5f0c8b942d93be6ac36a156c0ba44c86c3698f91)
+++ device/device.go	(date 1615902577566)
@@ -305,12 +305,12 @@
 
 	cpus := runtime.NumCPU()
 	device.state.stopping.Wait()
-	device.queue.encryption.wg.Add(cpus) // One for each RoutineHandshake
+	device.queue.encryption.wg.Add(cpus)
 	for i := 0; i < cpus; i++ {
 		go device.RoutineEncryption()
 		go device.RoutineDecryption()
-		go device.RoutineHandshake()
-	}
+	}
+	go device.RoutineHandshake()
 
 	device.state.stopping.Add(1)      // RoutineReadFromTUN
 	device.queue.encryption.wg.Add(1) // RoutineReadFromTUN


> On 1. 3. 2021, at 15:08, Laura Zelenku <laura.zelenku at wandera.com> wrote:
> 
> Hi Jason,
> I?ll try to explain the issue.
> 
> For incomming hanshake, the `handshake.state` is changing in the following way:
> 1. set state handshakeInitiationConsumed
> 2. check the state is handshakeInitiationConsumed otherwise "handshake initiation must be consumed first? error
> 3. set state handshakeResponseCreated
> 4. check the state is handshakeResponseCreated, otherwise "invalid state for keypair derivation? error
> 5. set state handshakeZeroed
> 
> For outgoing handshake the `handshake.state` is changing:
> 1. set state handshakeInitiationCreated
> 2. <sending handshake and waiting for response>
> 3. check the state is handshakeInitiationCreated, otherwise skip the packet
> 4. set state handshakeResponseConsumed
> 5. check the state is handshakeResponseConsumed, otherwise "invalid state for keypair derivation? error
> 6. set state handshakeZeroed
> 
> Usually only ?client? is sending handshake initiations and the ?server? responding. But in case some delay (e.g. cause by some network issues mainly for mobile devices) the ?server? can start sending handshake initiations (expiredNewHandshake or expiredRetransmitHandshake timers). In this time the client and server are sending hanshake initiations against each other. "go device.RoutineHandshake()? is running in multiple threads. `handshake.state` is defined per peer. Two threads (RoutineHandshake) can process both handshakes (incomming, outgoing) in the same time and these threads are working with shared resource, handshake.state. Because the routine is expecting state that was set before and the second thread can modify the state, the routine can fail on checking the expected handshake.state.
> This is happening to us. We are getting error "handshake initiation must be consumed first?. handshakeInitiationConsumed is expected but handshakeZeroed is actually set (set by different thread). The error is logged on error level (Failed to create response message).
> 
> Hope this will help to understand the issue well.
> 
> Laura
> 
> 
>> On 25 Feb 2021, at 12:23, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> 
>> Hi Laura,
>> 
>> I'm not sure this is actually a problem. The latest handshake message
>> should probably win the race. I don't see state machine or data
>> corruption here, but just one handshake interrupting another, which is
>> par for the course with WireGuard.
>> 
>> Or have I overlooked something important in the state machine implementation?
>> 
>> Jason
> 


-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

From kevans at freebsd.org  Tue Mar 16 16:48:56 2021
From: kevans at freebsd.org (Kyle Evans)
Date: Tue, 16 Mar 2021 11:48:56 -0500
Subject: Removing WireGuard Support From FreeBSD Base
Message-ID: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>

Hi,

You may have recently noticed some chatter around the internet about
FreeBSD's in-kernel WireGuard implementation, and the work we've done
on it in the last week.  You may have also noticed additional chatter
afterwards with regards to the original implementation.  I'd like to give
some context and information with regards to the current situation, as
well as provide some insight into the future as one of the developers
involved.

With regard to the original implementation, this will be my only
commentary on the matter. I'm a developer, and I'm passionate
about the work that I do- often to a fault. I've said some things that
I regret; the accusations that Scott Long alluded to in an e-mail on FreeBSD
mailing lists were indeed made by me, and his phrasing of what I
said was much kinder than it could have been. These were mistakes,
and I'm going to own that. However, my personal belief is that neither
Netgate, pfSense, nor the original developer deserved the level of
scorn and criticism that they've received in the past days from both the
press and the community at large.

In the next day or so, I will be committing a removal of all WireGuard
related bits from our 'main' branch, including the work that I recently
committed. It will be followed up by a removal of the implementation
from stable/13, and we will seek appropriate approval to remove it
from releng/13.0 as well. Please, do not be concerned by any of this;
this is being done with mutual support from all parties.

Did the original implementation have issues? Yes, it did. Are we
certain that our new version -doesn't- have issues? I believe it
doesn't, but it hasn't been through thorough enough review. We hacked
on this for a week, and we all reviewed each others' work in the
process. The problem is that this work, in particular, is a driver with fairly
severe security implications. Review by "three developers working
and beating on it" is not the higher bar that we should be
holding this to. While I believed I was doing what's right for the
community, it's become clear that what's right for the community is
to take a step back and do this the right way.

Note that we're not dropping this effort. We will continue iterating
on this out-of-tree, and we will go through the proper review
channels. Folks will be unhappy in the interim because we're removing
it right now, but in the end we will have a better FreeBSD because of
it. There will be a kernel module available in ports at some point,
but not before it's ready.

Moving forward, myself, members of Netgate, and members of the larger
community *are* working together on strictly technical details. I urge
anyone with an interest in reviewing the driver to also get in touch with me.
Please, let's move forward as a community on this.

Thank you,

Kyle Evans

From noloader at gmail.com  Tue Mar 16 17:13:36 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 16 Mar 2021 13:13:36 -0400
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
Message-ID: <CAH8yC8=3o+xDJH25DCWgMCaWbQpViX5QSAvud-ufZb7jpR03bg@mail.gmail.com>

Hi Kyle,

I'm going to top post because there's only two points to raise. Sorry
about that.

I don't have a dog in this fight, so take this with a grain of salt...

> Netgate, pfSense, nor the original developer deserved the level of
> scorn and criticism that they've received in the past days from both the
> press and the community at large.

I have not really seen any scorn or criticism by the press or
community. But maybe my feeds are missing something...

> In the next day or so, I will be committing a removal of all WireGuard
> related bits from our 'main' branch, including the work that I recently
> committed. It will be followed up by a removal of the implementation
> from stable/13, and we will seek appropriate approval to remove it
> from releng/13.0 as well. Please, do not be concerned by any of this;
> this is being done with mutual support from all parties.

The thing I find unusual is, the move appears to lack technical
justification. The best I can tell, the reasons seem to be political.
But like I said, maybe my feeds are missing something...

As a naive outsider, if you are going to yank it, then the technical
reasons for the action should be clearly enumerated. Everything else
is just chatter or noise. The move just looks like a bunch of bruised
egos and sour grapes.

Maybe a good middle ground would be to take the existing code and put
it in a Wireguard branch. Those who wish to keep Wireguard out of
FreeBSD mainline have done so. FreeBSD users who wish to use Wireguard
can build the Wireguard branch. And those who wish to improve
Wireguard have a working branch for patches. Later, the branch can be
re-merged back to master.

Jeff

On Tue, Mar 16, 2021 at 12:51 PM Kyle Evans <kevans at freebsd.org> wrote:
>
> You may have recently noticed some chatter around the internet about
> FreeBSD's in-kernel WireGuard implementation, and the work we've done
> on it in the last week.  You may have also noticed additional chatter
> afterwards with regards to the original implementation.  I'd like to give
> some context and information with regards to the current situation, as
> well as provide some insight into the future as one of the developers
> involved.
>
> With regard to the original implementation, this will be my only
> commentary on the matter. I'm a developer, and I'm passionate
> about the work that I do- often to a fault. I've said some things that
> I regret; the accusations that Scott Long alluded to in an e-mail on FreeBSD
> mailing lists were indeed made by me, and his phrasing of what I
> said was much kinder than it could have been. These were mistakes,
> and I'm going to own that. However, my personal belief is that neither
> Netgate, pfSense, nor the original developer deserved the level of
> scorn and criticism that they've received in the past days from both the
> press and the community at large.
>
> In the next day or so, I will be committing a removal of all WireGuard
> related bits from our 'main' branch, including the work that I recently
> committed. It will be followed up by a removal of the implementation
> from stable/13, and we will seek appropriate approval to remove it
> from releng/13.0 as well. Please, do not be concerned by any of this;
> this is being done with mutual support from all parties.
>
> Did the original implementation have issues? Yes, it did. Are we
> certain that our new version -doesn't- have issues? I believe it
> doesn't, but it hasn't been through thorough enough review. We hacked
> on this for a week, and we all reviewed each others' work in the
> process. The problem is that this work, in particular, is a driver with fairly
> severe security implications. Review by "three developers working
> and beating on it" is not the higher bar that we should be
> holding this to. While I believed I was doing what's right for the
> community, it's become clear that what's right for the community is
> to take a step back and do this the right way.
>
> Note that we're not dropping this effort. We will continue iterating
> on this out-of-tree, and we will go through the proper review
> channels. Folks will be unhappy in the interim because we're removing
> it right now, but in the end we will have a better FreeBSD because of
> it. There will be a kernel module available in ports at some point,
> but not before it's ready.
>
> Moving forward, myself, members of Netgate, and members of the larger
> community *are* working together on strictly technical details. I urge
> anyone with an interest in reviewing the driver to also get in touch with me.
> Please, let's move forward as a community on this.

From Jason at zx2c4.com  Tue Mar 16 17:30:13 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 16 Mar 2021 11:30:13 -0600
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
Message-ID: <CAHmME9rZRQ3ncWx6kfN21DXC-w55A5srYe3s7gdOxjN=hXL8pA@mail.gmail.com>

Hi Kyle,

I think what you describe is a great plan. I think everybody realizes
at this point that the original code base from the original author
never should have been merged. We went head first in trying to fix it
in a week because we thought that was our only choice. But knowing now
that we can simply remove it, and get back to coding it carefully and
deliberately, is just a huge relief. So that's great. And while it's
under development, we can have an out-of-tree repo for folks to test
out intermediate snapshots and provide feedback, just like the
WireGuard project has always done. In other words, we'll follow the
tried and true formulation of: slow, careful coding + regular
snapshots to receive testing and feedback.

So, I'm quite happy there. And when it is ready, I'm confident it'll
get a thorough review from FreeBSD core developers, which is terrific.
More review ==> better code.

I also want to thank you for your words about Netgate and the various
parties involved. I think nobody wants animosity and tension, and I
imagine your email has helped to calm the tone quite a bit. That's
just the type of reset we need, so that we can get back to what we do
best: writing and refining code.

To others reading, with regards to actual project logistics, I think
what I wrote in the original announcement still stands: we'll have
instructions for module building and such online and we'll announce it
here. And for developers interested, Kyle, MattD, and I have been
coordinating code writing on IRC; if you'd like to join in, ping one
of us there and we'll get you up to speed on repos and ssh keys
whatnot.

Regards,
Jason

From Jason at zx2c4.com  Tue Mar 16 17:37:59 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 16 Mar 2021 11:37:59 -0600
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <CAH8yC8=3o+xDJH25DCWgMCaWbQpViX5QSAvud-ufZb7jpR03bg@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
 <CAH8yC8=3o+xDJH25DCWgMCaWbQpViX5QSAvud-ufZb7jpR03bg@mail.gmail.com>
Message-ID: <CAHmME9rFU8dknvVfWmRgbLud2bkQMNvVSBqNUfUiBcnTgV90yA@mail.gmail.com>

Hi Jeffrey,

On Tue, Mar 16, 2021 at 11:16 AM Jeffrey Walton <noloader at gmail.com> wrote:
> > In the next day or so, I will be committing a removal of all WireGuard
> > related bits from our 'main' branch, including the work that I recently
> > committed. It will be followed up by a removal of the implementation
> > from stable/13, and we will seek appropriate approval to remove it
> > from releng/13.0 as well. Please, do not be concerned by any of this;
> > this is being done with mutual support from all parties.
>
> The thing I find unusual is, the move appears to lack technical
> justification. The best I can tell, the reasons seem to be political.
> But like I said, maybe my feeds are missing something...
>
> As a naive outsider, if you are going to yank it, then the technical
> reasons for the action should be clearly enumerated. Everything else
> is just chatter or noise. The move just looks like a bunch of bruised
> egos and sour grapes.


I'd just like to chime in and point out that although this is
happening in a political context as you've pointed out, this is in my
opinion the *best possible technical situation*, and the one I would
have preferred in the beginning anyway if it were presented as a
choice.

Here's the technical background you asked for:
- We found tons of issues with the original code base.
- We spent a week rewriting that codebase.
So here's the rationale:
- Merging a week-old codebase into an operating system kernel is a bad idea.

It's really not more complicated than that. I'm *sure* we'll find more
things to fix. That's just the nature of it.

And from a practical perspective, it's a lot easier for me, anyway, to
casually push fixes as I code to a normal repo on git.zx2c4.com. When
there's a lot of potential code churn, sometimes it's easiest to be
able to move fast at first. When we get it to a place where we feel
extra good about it, then we can do the full review process on what
we've got, which has the added benefit of even more eyeballs and ways
of looking at things. I think the code will benefit from this type of
process.


> Maybe a good middle ground would be to take the existing code and put
> it in a Wireguard branch. Those who wish to keep Wireguard out of
> FreeBSD mainline have done so. FreeBSD users who wish to use Wireguard
> can build the Wireguard branch. And those who wish to improve
> Wireguard have a working branch for patches. Later, the branch can be
> re-merged back to master.

We're actually going to do something like that already. We'll have it
as an out-of-tree module, since it's fairly standalone anyway. And
then when it's ready, we'll send that for merging back into the
FreeBSD main branch. Also, from a technical perspective, dealing with
out of tree modules on FreeBSD seems way, way easier than on Linux.
There's not nearly as much API churn, as far as I can see. We probably
can even offer prebuilts at some point for people who want to test out
snapshots. So I'm really not very worried (at least at the moment; I'm
still new to FreeBSD kernel development).

Jason

From nicolai-wireguard at chocolatine.org  Tue Mar 16 18:24:30 2021
From: nicolai-wireguard at chocolatine.org (Nicolai)
Date: Tue, 16 Mar 2021 18:24:30 +0000
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <CAHmME9rFU8dknvVfWmRgbLud2bkQMNvVSBqNUfUiBcnTgV90yA@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
 <CAH8yC8=3o+xDJH25DCWgMCaWbQpViX5QSAvud-ufZb7jpR03bg@mail.gmail.com>
 <CAHmME9rFU8dknvVfWmRgbLud2bkQMNvVSBqNUfUiBcnTgV90yA@mail.gmail.com>
Message-ID: <20210316182430.GA42183@chocolatine.org>

On Tue, Mar 16, 2021 at 11:37:59AM -0600, Jason A. Donenfeld wrote:

> Here's the technical background you asked for:
> - We found tons of issues with the original code base.
> - We spent a week rewriting that codebase.
> So here's the rationale:
> - Merging a week-old codebase into an operating system kernel is a bad idea.

Yeah, when I saw the recent sudden work to get WireGuard into FreeBSD
13, I was excited but also nervous since it's been in beta/RC for a
while, just a bit late to introduce important features.  I think the
current plan is sensible and will produce a result everyone likes.

> We probably can even offer prebuilts at some point for people who want
> to test out snapshots.

That's a great idea!  WireGuard is what finally got me to run
OpenBSD-current, so I could test the snaps.

Nicolai

From c.schmitt at envisia.de  Tue Mar 16 21:28:35 2021
From: c.schmitt at envisia.de (Christian Schmitt)
Date: Tue, 16 Mar 2021 21:28:35 +0000
Subject: dynamic peer configuration over socket?
Message-ID: <4fa1c016-9fcb-b1ab-2df6-be774ac6344d@envisia.de>

Hello,

currently I'm toying a little bit with wireguard and found the 
configuration really really simple.

at the moment I'm using openvpn and want to replace it. with openvpn we 
dynamically add peers by using the management api.

we have a watcher program that listens the management sockets and 
watches until openvpn sends us something like 
(https://openvpn.net/community-resources/management-interface/ 
--management-client-auth):

 > MGMT: connect client:

we than need to respond with either client-kill or client-auth 
(asynchronously).


this is extremly helpful because it means we can have a database where 
all our peer configuration is held and openvpn asks if the client allowed.

I could not find something like that with wireguard, the only way I 
would find, if our service would poll for new configuration and apply it 
if wireguard does not know the peer, but this is error prone and does 
not work in my ha topology that well. is there something planned to make 
that happen? it's btw. also painful to manage such a big config with 
hundreds of client peers.


Best Regards

 ?Christian


From lifeng1519 at gmail.com  Wed Mar 17 05:30:58 2021
From: lifeng1519 at gmail.com (Feng Li)
Date: Wed, 17 Mar 2021 13:30:58 +0800
Subject: Enhance the "AllowedIPs"
In-Reply-To: <b7fb35f2-5d82-b4d6-5add-e18f5d032010@spam-free.eu>
References: <CAEK8JBC6Y7utcom7YCz5AX=bHPOkc6cOdMoMKTC=QhqBQwDp_A@mail.gmail.com>
 <b7fb35f2-5d82-b4d6-5add-e18f5d032010@spam-free.eu>
Message-ID: <CAEK8JBBpJRo1ShMGJfSRU8OASEDd+LRFWLp0GFRkR7=ruPz1yQ@mail.gmail.com>

Thanks.

Add a route is simple on Linux, But it's not simple for other
platforms, like Windows.
So changes the AllowedIPs is the best option.

On Tue, Mar 16, 2021 at 7:40 PM Chris <wireguard at spam-free.eu> wrote:
>
> Just in case:
> I guess you have already thought about using the post script to add a separate
> route to 192.160.0.0/16 using the original path with a lower metric.
>
> On 15/03/2021 08:57, Feng Li wrote:
> > Hi,
> >
> > As we know, the AllowedIPs will set the route table. However, if we
> > want to set the CIDR, but except for some CIDR range, it's not so easy
> > and out of the box. For example, if I want to route my all traffic,
> > except the 192.168.0.0/16. I have to calculate the two CIDR
> > difference:
> >
> > AllowedIPs =
> > 0.0.0.0/1 + 128.0.0.0/1 - 192.168.0.0/16
> > =
> > 0.0.0.0/5,8.0.0.0/7,11.0.0.0/8,12.0.0.0/6,16.0.0.0/4,32.0.0.0/3,64.0.0.0/2,128.0.0.0/2,192.0.0.0/9,192.128.0.0/11,192.160.0.0/13,192.169.0.0/16,192.170.0.0/15,192.172.0.0/14,192.176.0.0/12,192.192.0.0/10,193.0.0.0/8,194.0.0.0/7,196.0.0.0/6,200.0.0.0/5,208.0.0.0/4,224.0.0.0/3,10.99.0.0/24
> >
> > Is it possible to be built in Wireguard in the future? I think it's very useful.
> >
> > The discussion link is here:
> > https://www.reddit.com/r/WireGuard/comments/m44fi5/enhance_the_allowedips/
> >
> > Thanks.
>

From laura.zelenku at wandera.com  Wed Mar 17 07:55:26 2021
From: laura.zelenku at wandera.com (Laura Zelenku)
Date: Wed, 17 Mar 2021 08:55:26 +0100
Subject: [PATCH] Respect WG protocol reserved bytes
Message-ID: <9C811F88-FD21-47D0-B3FE-A14FD5BC1816@wandera.com>

Packet that respects WG protocol contains Type on first byte followed by
three reserved bytes. Because wireguard-go implementation uses element
pools it is required to make sure that reserved bytes are cleared for
outgoing traffic (can get dirty by "bad" clients). Clearing reserved
bytes is also for backwards compatibility.

Signed-off-by: Laura Zelenku <laura.zelenku at wandera.com>
---
 device/noise-protocol.go | 12 ++++++++----
 device/receive.go        |  4 ++--
 device/send.go           |  6 ++++--
 3 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/device/noise-protocol.go b/device/noise-protocol.go
index 0212b7d..b5ef72b 100644
--- a/device/noise-protocol.go
+++ b/device/noise-protocol.go
@@ -82,7 +82,8 @@ const (
  */
 
 type MessageInitiation struct {
-       Type      uint32
+       Type      uint8
+       Reserved  [3]byte
        Sender    uint32
        Ephemeral NoisePublicKey
        Static    [NoisePublicKeySize + poly1305.TagSize]byte
@@ -92,7 +93,8 @@ type MessageInitiation struct {
 }
 
 type MessageResponse struct {
-       Type      uint32
+       Type      uint8
+       Reserved  [3]byte
        Sender    uint32
        Receiver  uint32
        Ephemeral NoisePublicKey
@@ -102,14 +104,16 @@ type MessageResponse struct {
 }
 
 type MessageTransport struct {
-       Type     uint32
+       Type     uint8
+       Reserved [3]byte
        Receiver uint32
        Counter  uint64
        Content  []byte
 }
 
 type MessageCookieReply struct {
-       Type     uint32
+       Type     uint8
+       Reserved [3]byte
        Receiver uint32
        Nonce    [chacha20poly1305.NonceSizeX]byte
        Cookie   [blake2s.Size128 + poly1305.TagSize]byte
diff --git a/device/receive.go b/device/receive.go
index b1959c6..e0d57bc 100644
--- a/device/receive.go
+++ b/device/receive.go
@@ -22,7 +22,7 @@ import (
 )
 
 type QueueHandshakeElement struct {
-       msgType  uint32
+       msgType  uint8
        packet   []byte
        endpoint conn.Endpoint
        buffer   *[MaxMessageSize]byte
@@ -121,7 +121,7 @@ func (device *Device) RoutineReceiveIncoming(IP int, bind conn.Bind) {
                // check size of packet
 
                packet := buffer[:size]
-               msgType := binary.LittleEndian.Uint32(packet[:4])
+               msgType := packet[0]
 
                var okay bool
 
diff --git a/device/send.go b/device/send.go
index a437cf1..dc4a8e2 100644
--- a/device/send.go
+++ b/device/send.go
@@ -373,11 +373,13 @@ func (device *Device) RoutineEncryption() {
                // populate header fields
                header := elem.buffer[:MessageTransportHeaderSize]
 
-               fieldType := header[0:4]
+               fieldType := header[0:1]
+               fieldReserved := header[1:4]
                fieldReceiver := header[4:8]
                fieldNonce := header[8:16]
 
-               binary.LittleEndian.PutUint32(fieldType, MessageTransportType)
+               fieldType[0] = byte(MessageTransportType)
+               copy(fieldReserved, []byte{}) // clear reserved bytes
                binary.LittleEndian.PutUint32(fieldReceiver, elem.keypair.remoteIndex)
                binary.LittleEndian.PutUint64(fieldNonce, elem.nonce)
 
-- 
2.28.0



-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

From me at aaronmdjones.net  Wed Mar 17 12:35:56 2021
From: me at aaronmdjones.net (Aaron Jones)
Date: Wed, 17 Mar 2021 12:35:56 +0000
Subject: [PATCH] Respect WG protocol reserved bytes
In-Reply-To: <9C811F88-FD21-47D0-B3FE-A14FD5BC1816@wandera.com>
References: <9C811F88-FD21-47D0-B3FE-A14FD5BC1816@wandera.com>
Message-ID: <f5126d40-4ea7-193a-93dd-ab816af3bb7e@aaronmdjones.net>

On 17/03/2021 07:55, Laura Zelenku wrote:
> Packet that respects WG protocol contains Type on first byte followed by
> three reserved bytes. Because wireguard-go implementation uses element
> pools it is required to make sure that reserved bytes are cleared for
> outgoing traffic (can get dirty by "bad" clients). Clearing reserved
> bytes is also for backwards compatibility.

Encoding the message type as a little-endian 32-bit integer already
takes care of setting the reserved bytes to zero; e.g. for a packet of
message type 1 (handshake initiation), its little-endian 32-bit encoding
is the following sequence of bytes: [ 0x01 0x00 0x00 0x00 ].

This is also the approach used for checking message types on the
receiving end, so packets whose reserved bytes are non-zero are already
discarded as being those of unknown types of message.

Regards,
Aaron Jones

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210317/c7db4502/attachment.sig>

From b.braunger at syseleven.de  Wed Mar 17 12:36:25 2021
From: b.braunger at syseleven.de (Benedikt Braunger)
Date: Wed, 17 Mar 2021 13:36:25 +0100
Subject: [PATCH] added ipv6_dst_lookup_flow define for VZ7 kernels
In-Reply-To: <20210304183018.42658-1-b.braunger@syseleven.de>
References: <20210304183018.42658-1-b.braunger@syseleven.de>
Message-ID: <6ea1abc2-7620-3832-1c70-040c1b9fe309@syseleven.de>

Hi,

Is anything blocking this from getting merged into wireguard-compat?

Regards,
Beni

On 3/4/21 7:30 PM, Benedikt Braunger wrote:
> This patch adds an additional check for OpenVZ / Virtuozzo 7 custom
> kernels to ensure ipv6_dst_lookup_flow is defined.
> It also splits the very long version checking into multiple lines for
> better reading.
>
> Signed-off-by: Benedikt Braunger <b.braunger at syseleven.de>
> ---
> Since the error mentioned in "Wireguard DKMS build on OpenVZ 7" still
> occures, I searched for a way to check if the module is compiled on 
> a VZ kernel. This patch works for me, I tested on Virtuozzo 7 and 
> plain CentOS 7. Can compile on both without error and the module is
> loadable.
> Probably Virtuozzo will backuport ipv6_dst_lookup_flow some day but
> they can't (or don't want to) tell me when.
> If so one can compare VZVERSION to the current one to ensure the definition
> for older verions.
>
>  src/compat/compat.h | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/compat/compat.h b/src/compat/compat.h
> index 3e8e005..7700e7b 100644
> --- a/src/compat/compat.h
> +++ b/src/compat/compat.h
> @@ -91,7 +91,13 @@
>  
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) && LINUX_VERSION_CODE >= KERNEL_VERSION(3, 16, 83)
>  #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup_flow(b, c, d)
> -#elif (LINUX_VERSION_CODE < KERNEL_VERSION(5, 4, 5) && LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(5, 3, 18) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0) && !defined(ISUBUNTU1904)) || (!defined(ISRHEL8) && !defined(ISDEBIAN) && !defined(ISUBUNTU1804) && LINUX_VERSION_CODE < KERNEL_VERSION(4, 19, 119) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 15, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 181) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 9, 224) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 5, 0)) || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 4, 224) && !defined(ISUBUNTU1604) && !defined(ISRHEL7))
> +#elif (LINUX_VERSION_CODE < KERNEL_VERSION(5, 4, 5) && LINUX_VERSION_CODE >= KERNEL_VERSION(5, 4, 0))\
> +  || (LINUX_VERSION_CODE < KERNEL_VERSION(5, 3, 18) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0) && !defined(ISUBUNTU1904))\
> +  || (!defined(ISRHEL8) && !defined(ISDEBIAN) && !defined(ISUBUNTU1804) && LINUX_VERSION_CODE < KERNEL_VERSION(4, 19, 119) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 15, 0))\
> +  || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 14, 181) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 10, 0))\
> +  || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 9, 224) && LINUX_VERSION_CODE >= KERNEL_VERSION(4, 5, 0))\
> +  || (LINUX_VERSION_CODE < KERNEL_VERSION(4, 4, 224) && !defined(ISUBUNTU1604) && !defined(ISRHEL7))\
> +  || (LINUX_VERSION_CODE == KERNEL_VERSION(3, 10, 0) && defined(ISRHEL7) && defined(VZVERSION))
>  #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup(a, b, &dst, c) + (void *)0 ?: dst
>  #endif
>  

From laura.zelenku at wandera.com  Wed Mar 17 12:53:22 2021
From: laura.zelenku at wandera.com (Laura Zelenku)
Date: Wed, 17 Mar 2021 13:53:22 +0100
Subject: [PATCH] Respect WG protocol reserved bytes
In-Reply-To: <f5126d40-4ea7-193a-93dd-ab816af3bb7e@aaronmdjones.net>
References: <9C811F88-FD21-47D0-B3FE-A14FD5BC1816@wandera.com>
 <f5126d40-4ea7-193a-93dd-ab816af3bb7e@aaronmdjones.net>
Message-ID: <2240E688-898B-4F74-B954-0754464F6352@wandera.com>

If the client send some data in reserved bytes you will have logs full of errors because the message gets type from 4 bytes instead of 1 byte (like it is in protocol description).
I would like implementation respects protocol - https://www.wireguard.com/papers/wireguard.pdf . Yes, in our project we use reserved bytes.

I know that when there are zeros in reserved bytes, everything is correct. But if you receive some non-zero value in reserved bytes?

Laura

> On 17. 3. 2021, at 13:35, Aaron Jones <me at aaronmdjones.net> wrote:
> 
> On 17/03/2021 07:55, Laura Zelenku wrote:
>> Packet that respects WG protocol contains Type on first byte followed by
>> three reserved bytes. Because wireguard-go implementation uses element
>> pools it is required to make sure that reserved bytes are cleared for
>> outgoing traffic (can get dirty by "bad" clients). Clearing reserved
>> bytes is also for backwards compatibility.
> 
> Encoding the message type as a little-endian 32-bit integer already
> takes care of setting the reserved bytes to zero; e.g. for a packet of
> message type 1 (handshake initiation), its little-endian 32-bit encoding
> is the following sequence of bytes: [ 0x01 0x00 0x00 0x00 ].
> 
> This is also the approach used for checking message types on the
> receiving end, so packets whose reserved bytes are non-zero are already
> discarded as being those of unknown types of message.
> 
> Regards,
> Aaron Jones
> 


-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

From gbe at freebsd.org  Wed Mar 17 12:53:28 2021
From: gbe at freebsd.org (Gordon Bergling)
Date: Wed, 17 Mar 2021 13:53:28 +0100
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
Message-ID: <YFH7yIJ9OImHUwYO@lion.0xfce3.net>

I am not sure, if the removal is a great idea, a removal from
releng/13 and stable/13 - possibly yes, but from main?

This is still -CURRENT and -CURRENT should be central place for development,
even if we have phabricator for review.

If the complete backout is happening, please don't forget the manual
page. I have spend a lot of time on it, while OpenBSD made a good
template.

--Gordon

On Tue, Mar 16, 2021 at 11:48:56AM -0500, Kyle Evans wrote:
> Hi,
> 
> You may have recently noticed some chatter around the internet about
> FreeBSD's in-kernel WireGuard implementation, and the work we've done
> on it in the last week.  You may have also noticed additional chatter
> afterwards with regards to the original implementation.  I'd like to give
> some context and information with regards to the current situation, as
> well as provide some insight into the future as one of the developers
> involved.
> 
> With regard to the original implementation, this will be my only
> commentary on the matter. I'm a developer, and I'm passionate
> about the work that I do- often to a fault. I've said some things that
> I regret; the accusations that Scott Long alluded to in an e-mail on FreeBSD
> mailing lists were indeed made by me, and his phrasing of what I
> said was much kinder than it could have been. These were mistakes,
> and I'm going to own that. However, my personal belief is that neither
> Netgate, pfSense, nor the original developer deserved the level of
> scorn and criticism that they've received in the past days from both the
> press and the community at large.
> 
> In the next day or so, I will be committing a removal of all WireGuard
> related bits from our 'main' branch, including the work that I recently
> committed. It will be followed up by a removal of the implementation
> from stable/13, and we will seek appropriate approval to remove it
> from releng/13.0 as well. Please, do not be concerned by any of this;
> this is being done with mutual support from all parties.
> 
> Did the original implementation have issues? Yes, it did. Are we
> certain that our new version -doesn't- have issues? I believe it
> doesn't, but it hasn't been through thorough enough review. We hacked
> on this for a week, and we all reviewed each others' work in the
> process. The problem is that this work, in particular, is a driver with fairly
> severe security implications. Review by "three developers working
> and beating on it" is not the higher bar that we should be
> holding this to. While I believed I was doing what's right for the
> community, it's become clear that what's right for the community is
> to take a step back and do this the right way.
> 
> Note that we're not dropping this effort. We will continue iterating
> on this out-of-tree, and we will go through the proper review
> channels. Folks will be unhappy in the interim because we're removing
> it right now, but in the end we will have a better FreeBSD because of
> it. There will be a kernel module available in ports at some point,
> but not before it's ready.
> 
> Moving forward, myself, members of Netgate, and members of the larger
> community *are* working together on strictly technical details. I urge
> anyone with an interest in reviewing the driver to also get in touch with me.
> Please, let's move forward as a community on this.
> 
> Thank you,
> 
> Kyle Evans
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210317/9288115f/attachment.sig>

From Jason at zx2c4.com  Wed Mar 17 13:10:50 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 17 Mar 2021 07:10:50 -0600
Subject: [PATCH] Respect WG protocol reserved bytes
In-Reply-To: <2240E688-898B-4F74-B954-0754464F6352@wandera.com>
References: <9C811F88-FD21-47D0-B3FE-A14FD5BC1816@wandera.com>
 <f5126d40-4ea7-193a-93dd-ab816af3bb7e@aaronmdjones.net>
 <2240E688-898B-4F74-B954-0754464F6352@wandera.com>
Message-ID: <CAHmME9rkLGQb9nGpoLwDt4V-D+rv43JU_mmT96ww1wQfTnSpmw@mail.gmail.com>

On 3/17/21, Laura Zelenku <laura.zelenku at wandera.com> wrote:
> If the client send some data in reserved bytes you will have logs full of
> errors because the message gets type from 4 bytes instead of 1 byte (like it
> is in protocol description).
> I would like implementation respects protocol -
> https://www.wireguard.com/papers/wireguard.pdf . Yes, in our project we use
> reserved bytes.
>
> I know that when there are zeros in reserved bytes, everything is correct.
> But if you receive some non-zero value in reserved bytes?
>

Aaron is right.

Those bytes MUST be set to zero. Otherwise you're now implementing a
different protocol. Do not use reserved bytes. They are not reserved
for you.

From mjt at tls.msk.ru  Wed Mar 17 15:28:06 2021
From: mjt at tls.msk.ru (Michael Tokarev)
Date: Wed, 17 Mar 2021 18:28:06 +0300
Subject: occasional stalls of a WG tunnel
Message-ID: <5b24bcef-79ef-dfa1-9686-4a644f3aa88d@msgid.tls.msk.ru>

Hi!

We're experiencing occasional stalls of a single (so far)
node in a star-like configuration.

The server in the center is a linux system with kernel 5.10.13
with a built-in wireguard module.  The client is a windows machine
with current wireguard software installed from the site.

Sometimes (which happened 3 times already), the tunnel stops
working, - no traffic goes within the tunnel as far as I can
see.  I'm not sure yet if the encrypted packets are flowing
between the two nodes, - at least the linux system is sending
them but I can't say for sure if the windows system does the
same, - this is something for me to watch the next time it
happens.

What can cure the tunnel immediately is a simple "refresh"
command, -

  wg setconf $if /etc/wireguard/$if.conf

- this makes the whole tunnel operational again immediately.

Other nodes of the tunnel are unaffected by this (except of
the momentary drop of service during the setconf operation
and the reconnect each node is doing after that).

The question is: how can I debug what's going on the next
time this happens, besides watching more closely which packets
are flowing?

Thanks,

/mjt

From Jason at zx2c4.com  Wed Mar 17 16:29:06 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 17 Mar 2021 10:29:06 -0600
Subject: [ANNOUNCE] WireGuard for FreeBSD snapshot 0.0.20210317 is available
Message-ID: <YFIuUos7XojJP/7L@zx2c4.com>

Hi,

An experimental snapshot, v0.0.20210317, of WireGuard for the FreeBSD
kernel has been tagged in the git repository:

    https://git.zx2c4.com/wireguard-freebsd/

This is the most recent module as it existed before we thankfully pulled
it from the 13.0 release in order to work on it more slowly here.  At
some point, we'll provide a package in ports for this, but not quite
yet. For now, you can build tags or build master, via:

    # git clone https://git.zx2c4.com/wireguard-freebsd
    # cd wireguard-freebsd/src
    # make load
    # make install

After that, it should be possible to use wg(8) and wg-quick(8) like
usual, but with the faster kernel implementation.

At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain security issues. We gladly
welcome your testing and bug reports, but do keep in mind that this code
is new, so some caution should be exercised at the moment for using it
in mission critical environments. In my small testing so far, however,
it seems to "basically work". And at the very least, those relying on
the code that was prior in the FreeBSD tree now have some immediate
continuity.

Over the next days and weeks, it can be expected that this repository
will improve and grow.

Enjoy!
Jason

From Jason at zx2c4.com  Wed Mar 17 18:34:02 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 17 Mar 2021 12:34:02 -0600
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <YFH7yIJ9OImHUwYO@lion.0xfce3.net>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
 <YFH7yIJ9OImHUwYO@lion.0xfce3.net>
Message-ID: <CAHmME9pqVfzWVsuTrC2eovbWTVeTSX086ZM6DSOK1ejPjkV3uQ@mail.gmail.com>

Hi Gordon,

On Wed, Mar 17, 2021 at 6:53 AM Gordon Bergling <gbe at freebsd.org> wrote:
> I am not sure, if the removal is a great idea, a removal from
> releng/13 and stable/13 - possibly yes, but from main?
>
> This is still -CURRENT and -CURRENT should be central place for development,
> even if we have phabricator for review.

It looks like Kyle has gone ahead with the revert anyway, so
development is now happening at:

https://git.zx2c4.com/wireguard-freebsd/

And there are now regular snapshot releases:

https://lists.zx2c4.com/pipermail/wireguard/2021-March/006518.html

As for your objections, and the question of what -CURRENT should or
shouldn't be used for, I really have no idea as a community outsider.
But I do look forward to submitting it for proper inclusion in
-CURRENT after a few more cycles of development and refinement.
There's also the crypto question that I'd welcome some feedback on:

https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057076.html

> If the complete backout is happening, please don't forget the manual
> page. I have spend a lot of time on it, while OpenBSD made a good
> template.

Thanks for bringing this up; I had actually forgotten about that. Do
you want to re-add it and keep that current as we develop? If you
email me your SSH key, you can just commit it directly.

Jason

From frank at harz.behrens.de  Wed Mar 17 19:29:12 2021
From: frank at harz.behrens.de (Frank Behrens)
Date: Wed, 17 Mar 2021 20:29:12 +0100
Subject: Wireguard for FreeBSD without iflib
In-Reply-To: <CAHmME9pqVfzWVsuTrC2eovbWTVeTSX086ZM6DSOK1ejPjkV3uQ@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
 <YFH7yIJ9OImHUwYO@lion.0xfce3.net>
 <CAHmME9pqVfzWVsuTrC2eovbWTVeTSX086ZM6DSOK1ejPjkV3uQ@mail.gmail.com>
Message-ID: <4621c1df-1fd0-489a-8a7d-b1731ae6626c@harz.behrens.de>

Hello Jason,

I read your messages from the last days in the freebsd lists.
In the version before removal from freebsd and in your current 
repository at https://git.zx2c4.com/wireguard-freebsd/ I see a problem.
I can't load the module, because I get the error:
Mar 17 20:07:53 <kern.crit> moon kernel: link_elf_obj: symbol 
qgroup_if_io_tqg undefined
Mar 17 20:07:53 <kern.crit> moon kernel: linker_load_file: 
/usr/local/src/wg/src/if_wg.ko - unsupported file type

I guess that is caused my the fact, that I do not have iflib in the 
kernel and you have only a TASKQGROUP_DECLARE(if_io_tqg) in the source 
and not TASKQGROUP_DEFINE(..).

Kind regards,
 ?? Frank
-- 

Frank Behrens
Osterwieck, Germany


From Jason at zx2c4.com  Wed Mar 17 22:17:59 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 17 Mar 2021 16:17:59 -0600
Subject: Wireguard for FreeBSD without iflib
In-Reply-To: <4621c1df-1fd0-489a-8a7d-b1731ae6626c@harz.behrens.de>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
 <YFH7yIJ9OImHUwYO@lion.0xfce3.net>
 <CAHmME9pqVfzWVsuTrC2eovbWTVeTSX086ZM6DSOK1ejPjkV3uQ@mail.gmail.com>
 <4621c1df-1fd0-489a-8a7d-b1731ae6626c@harz.behrens.de>
Message-ID: <CAHmME9qKqLnoFEJVk+3FH5Y7HM+6D=i6n=Ln4+HBntxjJpWWRw@mail.gmail.com>

Hi Frank,

On Wed, Mar 17, 2021 at 1:29 PM Frank Behrens <frank at harz.behrens.de> wrote:
> I read your messages from the last days in the freebsd lists.
> In the version before removal from freebsd and in your current
> repository at https://git.zx2c4.com/wireguard-freebsd/ I see a problem.
> I can't load the module, because I get the error:
> Mar 17 20:07:53 <kern.crit> moon kernel: link_elf_obj: symbol
> qgroup_if_io_tqg undefined
> Mar 17 20:07:53 <kern.crit> moon kernel: linker_load_file:
> /usr/local/src/wg/src/if_wg.ko - unsupported file type
>
> I guess that is caused my the fact, that I do not have iflib in the
> kernel and you have only a TASKQGROUP_DECLARE(if_io_tqg) in the source
> and not TASKQGROUP_DEFINE(..).

Thanks for the report. Indeed it may yet take more time to clear out
all the iflib stuff.

Fixed here:
https://git.zx2c4.com/wireguard-freebsd/commit/?id=39c05742f16da7f71f4c781759a4b5135916a249

And this will be available in the next snapshot.

Jason

From kevans at freebsd.org  Thu Mar 18 16:52:21 2021
From: kevans at freebsd.org (Kyle Evans)
Date: Thu, 18 Mar 2021 11:52:21 -0500
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
Message-ID: <CACNAnaHit=-=rNy2DFZg6=zs1XFBvqt10Ta-MTM79NSWu1AK0w@mail.gmail.com>

On Tue, Mar 16, 2021 at 11:48 AM Kyle Evans <kevans at freebsd.org> wrote:
>
> Hi,
>
> You may have recently noticed some chatter around the internet about
> FreeBSD's in-kernel WireGuard implementation, and the work we've done
> on it in the last week.  You may have also noticed additional chatter
> afterwards with regards to the original implementation.  I'd like to give
> some context and information with regards to the current situation, as
> well as provide some insight into the future as one of the developers
> involved.
>

I'm afraid I must follow this one up with an announcement that I'm
stepping back from the wireguard-freebsd efforts.

You'll likely hear some things about me in the coming days. I'm sure
I've said more things in the past week and a half in anger that I
regret, and I'll have to live with that. I'd like to set the record
straight. Netgate personnel were involved in part with my announcement
of removal. I did not take a number of suggestions, because I wrote
what I believed in and I continue to do so. Netgate is in no way
involved with this announcement that I'm leaving it for now. There's
been too much press surrounding this, and it's distracting me from the
work that I like to do and what I'm typically known for.

The wireguard-freebsd project will need a new maintainer.

Thanks,

Kyle Evans

From Jason at zx2c4.com  Thu Mar 18 16:57:35 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 18 Mar 2021 10:57:35 -0600
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <CACNAnaHit=-=rNy2DFZg6=zs1XFBvqt10Ta-MTM79NSWu1AK0w@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
 <CACNAnaHit=-=rNy2DFZg6=zs1XFBvqt10Ta-MTM79NSWu1AK0w@mail.gmail.com>
Message-ID: <CAHmME9ombhO5+YHTJugxG0rZEGOFLh6zOw2CnG8OQNAywEHtSQ@mail.gmail.com>

Hi Kyle,

On Thu, Mar 18, 2021 at 10:53 AM Kyle Evans <kevans at freebsd.org> wrote:
> involved with this announcement that I'm leaving it for now. There's
> been too much press surrounding this, and it's distracting me from the
> work that I like to do and what I'm typically known for.

Makes sense and is understandable. It's been pretty miserable for all of us.

It looks like we'll eventually find somebody on the FreeBSD side of
things to take over where you left off, but hopefully for now in the
coming weeks things can just level out to some tranquility, so we can
get back to distraction-free coding without all the drama.

Jason

From gbe at freebsd.org  Fri Mar 19 07:47:19 2021
From: gbe at freebsd.org (Gordon Bergling)
Date: Fri, 19 Mar 2021 08:47:19 +0100
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <CAHmME9pqVfzWVsuTrC2eovbWTVeTSX086ZM6DSOK1ejPjkV3uQ@mail.gmail.com>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
 <YFH7yIJ9OImHUwYO@lion.0xfce3.net>
 <CAHmME9pqVfzWVsuTrC2eovbWTVeTSX086ZM6DSOK1ejPjkV3uQ@mail.gmail.com>
Message-ID: <YFRXBzdglrzB18Ic@lion.0xfce3.net>

On Wed, Mar 17, 2021 at 12:34:02PM -0600, Jason A. Donenfeld wrote:
> Hi Gordon,
> 
> On Wed, Mar 17, 2021 at 6:53 AM Gordon Bergling <gbe at freebsd.org> wrote:
> > I am not sure, if the removal is a great idea, a removal from
> > releng/13 and stable/13 - possibly yes, but from main?
> >
> > This is still -CURRENT and -CURRENT should be central place for development,
> > even if we have phabricator for review.
> 
> It looks like Kyle has gone ahead with the revert anyway, so
> development is now happening at:
> 
> https://git.zx2c4.com/wireguard-freebsd/
> 
> And there are now regular snapshot releases:
> 
> https://lists.zx2c4.com/pipermail/wireguard/2021-March/006518.html
> 
> As for your objections, and the question of what -CURRENT should or
> shouldn't be used for, I really have no idea as a community outsider.
> But I do look forward to submitting it for proper inclusion in
> -CURRENT after a few more cycles of development and refinement.
> There's also the crypto question that I'd welcome some feedback on:
> 
> https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057076.html
> 
> > If the complete backout is happening, please don't forget the manual
> > page. I have spend a lot of time on it, while OpenBSD made a good
> > template.
> 
> Thanks for bringing this up; I had actually forgotten about that. Do
> you want to re-add it and keep that current as we develop? If you
> email me your SSH key, you can just commit it directly.
> 
> Jason

Thanks for the reply. I still think that the removal from main was a mistake,
but it has happened.

I'll create a port for WireGuard tomorrow so that FreeBSD isn't losing WireGuard
support at all, for whatever reason.

--Gordon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210319/870218ba/attachment.sig>

From kevans at freebsd.org  Fri Mar 19 13:03:01 2021
From: kevans at freebsd.org (Kyle Evans)
Date: Fri, 19 Mar 2021 08:03:01 -0500
Subject: =?UTF-8?Q?Re=3A_=5BANNOUNCE=5D_WireGuard_for_FreeBSD_in_development_?=
 =?UTF-8?Q?for_13=2Ey_=E2=80=93_and_a_note_of_how_we_got_here?=
In-Reply-To: <YE9zWanlutKYTlKL@zx2c4.com>
References: <YE9zWanlutKYTlKL@zx2c4.com>
Message-ID: <CACNAnaFsDK7moCr1j1GYLcEdR_UYE=My7vgKB6VLnFaNzKAzOw@mail.gmail.com>

On Mon, Mar 15, 2021 at 9:47 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi everybody,
>
> [... snip ...]
>
> The first step was assessing the current state of the code the previous
> developer had dumped into the tree. It was not pretty. I imagined
> strange Internet voices jeering, ?this is what gives C a bad name!?

This was a highly unnecessary jab.

> There were random sleeps added to ?fix? race conditions

This is true.

> validation functions that just returned true

I looked back at the history here just now, and I count one,
wg_allowedip_valid, that pretty much got ripped out anyways.

> catastrophic cryptographic vulnerabilities
> whole parts of the protocol unimplemented

I'm not qualified to speak about these two, which are perhaps the
worst from the public's perspective.

> kernel panics

These are true.

> security bypasses
> overflows

I only recall one of each.

> random printf statements deep in crypto code

This is true.

> the most spectacular buffer overflows

English is a crappy language, but this sounds like you're advertising
more than one.  There was one, and for the record to anyone watching to
dispel "the word on the street" that it's potentially an RCE: based on what's
happening I cannot imagine how you could usefully turn it into an RCE.
Local privileged execution, 100%, but looking at it further, you've got to be
pretty skilled to make it before killing the kernel elsewhere.

> and the whole litany of awful things that go wrong when people aren?t
> careful when they write C.

This is an exceedingly broad statement, and it would have been good to provide
some pointers to these.

> [...]

You know that I don't appreciate how you handled this initial communication,
as I've told you a number of times. Now that I look at the history again, I'm
even more disappointed in how you handled this because there are some
pretty broad statements in here and language that could go either way.

I've additionally recommended, as a developer and not in any kind of official
capacity, that we can't include if_wg in any future version of base.  We cannot
have our users being put at the risk of this kind of publicity if we
can't get security
advisories issued in time. Ports is a fine place, where security issues can be
addressed expeditiously and more in line with how the WireGuard project chooses
to handle them.

Thanks,

Kyle Evans

From kevans at freebsd.org  Fri Mar 19 13:38:05 2021
From: kevans at freebsd.org (Kyle Evans)
Date: Fri, 19 Mar 2021 08:38:05 -0500
Subject: =?UTF-8?Q?Re=3A_=5BANNOUNCE=5D_WireGuard_for_FreeBSD_in_development_?=
 =?UTF-8?Q?for_13=2Ey_=E2=80=93_and_a_note_of_how_we_got_here?=
In-Reply-To: <CACNAnaFsDK7moCr1j1GYLcEdR_UYE=My7vgKB6VLnFaNzKAzOw@mail.gmail.com>
References: <YE9zWanlutKYTlKL@zx2c4.com>
 <CACNAnaFsDK7moCr1j1GYLcEdR_UYE=My7vgKB6VLnFaNzKAzOw@mail.gmail.com>
Message-ID: <CACNAnaFzNhjB6OopJakOvN2=63iACe+kHWp+oy3Gf2wM3jkcFQ@mail.gmail.com>

On Fri, Mar 19, 2021 at 8:03 AM Kyle Evans <kevans at freebsd.org> wrote:
>
> On Mon, Mar 15, 2021 at 9:47 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> >
> > Hi everybody,
> >
> > [... snip ...]
> >
> > The first step was assessing the current state of the code the previous
> > developer had dumped into the tree. It was not pretty. I imagined
> > strange Internet voices jeering, ?this is what gives C a bad name!?
>
> This was a highly unnecessary jab.
>
> > There were random sleeps added to ?fix? race conditions
>
> This is true.
>
> > validation functions that just returned true
>
> I looked back at the history here just now, and I count one,
> wg_allowedip_valid, that pretty much got ripped out anyways.
>
> > catastrophic cryptographic vulnerabilities
> > whole parts of the protocol unimplemented
>
> I'm not qualified to speak about these two, which are perhaps the
> worst from the public's perspective.
>
> > kernel panics
>
> These are true.
>
> > security bypasses
> > overflows
>
> I only recall one of each.
>
> > random printf statements deep in crypto code
>
> This is true.
>
> > the most spectacular buffer overflows
>
> English is a crappy language, but this sounds like you're advertising
> more than one.  There was one, and for the record to anyone watching to
> dispel "the word on the street" that it's potentially an RCE: based on what's
> happening I cannot imagine how you could usefully turn it into an RCE.
> Local privileged execution, 100%, but looking at it further, you've got to be
> pretty skilled to make it before killing the kernel elsewhere.
>

Ah, I have to clarify this one; I suspect if you're acting as a wg
gateway, it's possible. It
still doesn't look like an easy one to exploit.

> > and the whole litany of awful things that go wrong when people aren?t
> > careful when they write C.
>
> This is an exceedingly broad statement, and it would have been good to provide
> some pointers to these.
>
> > [...]
>
> You know that I don't appreciate how you handled this initial communication,
> as I've told you a number of times. Now that I look at the history again, I'm
> even more disappointed in how you handled this because there are some
> pretty broad statements in here and language that could go either way.
>
> I've additionally recommended, as a developer and not in any kind of official
> capacity, that we can't include if_wg in any future version of base.  We cannot
> have our users being put at the risk of this kind of publicity if we
> can't get security
> advisories issued in time. Ports is a fine place, where security issues can be
> addressed expeditiously and more in line with how the WireGuard project chooses
> to handle them.
>
> Thanks,
>
> Kyle Evans

From john at jacobs.co.com  Thu Mar 18 18:49:53 2021
From: john at jacobs.co.com (John Jacobs)
Date: Thu, 18 Mar 2021 14:49:53 -0400
Subject: Removing WireGuard Support From FreeBSD Base
Message-ID: <E3CBD3D4-F383-4921-8539-517A6AA25732@jacobs.co.com>

Kyle, you (and others) have been put in a position you never should have been put in. You have earned respect from someone who could not be any more outside the community of core FreeBSD developers for behaving like an adult and publicly sharing your introspection. I?m sorry if this is seen as an inappropriate comment from an outsider, but I felt it important to say that the way you have conducted yourself over the past few days has been noticed, noted and appreciated. As a consumer of FreeBSD I move forward with my belief in the product stronger than ever.

From contact at evilham.com  Thu Mar 18 21:02:19 2021
From: contact at evilham.com (Evilham)
Date: Thu, 18 Mar 2021 22:02:19 +0100
Subject: [PATCH] Fix build on FreeBSD 13 after removal from base
Message-ID: <75ddd07a-8d31-4938-8480-540f1996c9ad@yggdrasil.evilham.com>

\o Hello,

noticed that after if_wg removal from stable/13 following patch is 
needed for compiling the module.

I'm currently lacking a 14/CURRENT machine to assert that the 
module compiles with these changes, but from checking the branch, 
it looks like these definitions are there already, I wouldn't 
think versions pre-13 should be affected by this.

Cheers and thank you for the efforts and... handling of things.

---
 src/compat.h | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/compat.h b/src/compat.h
index 6126e26..bc29c01 100644
--- a/src/compat.h
+++ b/src/compat.h
@@ -7,6 +7,9 @@
  */

 #include <sys/param.h>
+#if __FreeBSD_version < 1400000
+#include <sys/smp.h>
+#include <sys/gtaskqueue.h>
 #if __FreeBSD_version < 1300000
 #define VIMAGE

@@ -18,8 +21,6 @@
 #include <sys/malloc.h>
 #include <sys/proc.h>
 #include <sys/lock.h>
-#include <sys/smp.h>
-#include <sys/gtaskqueue.h>
 #include <sys/socketvar.h>
 #include <sys/protosw.h>
 #include <net/vnet.h>
@@ -39,6 +40,7 @@

 #undef atomic_load_ptr
 #define atomic_load_ptr(p) (*(volatile __typeof(*p) *)(p))
+#endif /* __FreeBSD_version < 1300000 */

 struct taskqgroup_cpu {
 	LIST_HEAD(, grouptask)	tgc_tasks;
@@ -67,7 +69,7 @@ static inline void taskqgroup_drain_all(struct 
taskqgroup *tqg)
 		gtaskqueue_drain_all(q);
 	}
 }
-#endif
+#endif /* __FreeBSD_version < 1400000 */

 #if __FreeBSD_version < 1202000
 static inline uint32_t arc4random_uniform(uint32_t bound)
--
2.30.1

From contact at evilham.com  Fri Mar 19 10:43:19 2021
From: contact at evilham.com (Evilham)
Date: Fri, 19 Mar 2021 11:43:19 +0100
Subject: Removing WireGuard Support From FreeBSD Base
In-Reply-To: <YFRXBzdglrzB18Ic@lion.0xfce3.net>
References: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>
 <YFH7yIJ9OImHUwYO@lion.0xfce3.net>
 <CAHmME9pqVfzWVsuTrC2eovbWTVeTSX086ZM6DSOK1ejPjkV3uQ@mail.gmail.com>
 <YFRXBzdglrzB18Ic@lion.0xfce3.net>
Message-ID: <5980672e-2c67-4c46-9e31-733515d70a41@yggdrasil.evilham.com>


On dv., mar? 19 2021, Gordon Bergling wrote:

> On Wed, Mar 17, 2021 at 12:34:02PM -0600, Jason A. Donenfeld 
> wrote:
>> Hi Gordon,
>>
>> On Wed, Mar 17, 2021 at 6:53 AM Gordon Bergling 
>> <gbe at freebsd.org> wrote:
>> > I am not sure, if the removal is a great idea, a removal from
>> > releng/13 and stable/13 - possibly yes, but from main?
>> >
>> > This is still -CURRENT and -CURRENT should be central place 
>> > for development,
>> > even if we have phabricator for review.
>>
>> It looks like Kyle has gone ahead with the revert anyway, so
>> development is now happening at:
>>
>> https://git.zx2c4.com/wireguard-freebsd/
>>
>> And there are now regular snapshot releases:
>>
>> https://lists.zx2c4.com/pipermail/wireguard/2021-March/006518.html
>>
>> As for your objections, and the question of what -CURRENT 
>> should or
>> shouldn't be used for, I really have no idea as a community 
>> outsider.
>> But I do look forward to submitting it for proper inclusion in
>> -CURRENT after a few more cycles of development and refinement.
>> There's also the crypto question that I'd welcome some feedback 
>> on:
>>
>> https://lists.freebsd.org/pipermail/freebsd-hackers/2021-March/057076.html
>>
>> > If the complete backout is happening, please don't forget the 
>> > manual
>> > page. I have spend a lot of time on it, while OpenBSD made a 
>> > good
>> > template.
>>
>> Thanks for bringing this up; I had actually forgotten about 
>> that. Do
>> you want to re-add it and keep that current as we develop? If 
>> you
>> email me your SSH key, you can just commit it directly.
>>
>> Jason
>
> Thanks for the reply. I still think that the removal from main 
> was a mistake,
> but it has happened.
>
> I'll create a port for WireGuard tomorrow so that FreeBSD isn't 
> losing WireGuard
> support at all, for whatever reason.
>
> --Gordon


If you do that, please take following tiny patch into account 
(missing from the git repo @zx2c4, posted to the WG ML awaiting 
moderation):

This is due to the removal commit form stable/13 and, from what I 
saw, didn't affect CURRENT or 12.

---
 src/compat.h | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/compat.h b/src/compat.h
index 6126e26..bc29c01 100644
--- a/src/compat.h
+++ b/src/compat.h
@@ -7,6 +7,9 @@
  */

 #include <sys/param.h>
+#if __FreeBSD_version < 1400000
+#include <sys/smp.h>
+#include <sys/gtaskqueue.h>
 #if __FreeBSD_version < 1300000
 #define VIMAGE

@@ -18,8 +21,6 @@
 #include <sys/malloc.h>
 #include <sys/proc.h>
 #include <sys/lock.h>
-#include <sys/smp.h>
-#include <sys/gtaskqueue.h>
 #include <sys/socketvar.h>
 #include <sys/protosw.h>
 #include <net/vnet.h>
@@ -39,6 +40,7 @@

 #undef atomic_load_ptr
 #define atomic_load_ptr(p) (*(volatile __typeof(*p) *)(p))
+#endif /* __FreeBSD_version < 1300000 */

 struct taskqgroup_cpu {
 	LIST_HEAD(, grouptask)	tgc_tasks;
@@ -67,7 +69,7 @@ static inline void taskqgroup_drain_all(struct 
taskqgroup *tqg)
 		gtaskqueue_drain_all(q);
 	}
 }
-#endif
+#endif /* __FreeBSD_version < 1400000 */

 #if __FreeBSD_version < 1202000
 static inline uint32_t arc4random_uniform(uint32_t bound)
--
2.30.1

From ashish.is at lostca.se  Thu Mar 18 20:28:38 2021
From: ashish.is at lostca.se (Ashish)
Date: Fri, 19 Mar 2021 01:58:38 +0530
Subject: Unable to serve TCP connections over wireguard interface on FreeBSD
 13.0-RC2
Message-ID: <e1a14dfa-014c-7740-6205-75cd96933dba@lostca.se>

Hi,

I'm running if_wg kernel module (git revision: 5ef4d3efa691e71) on
FreeBSD 13.0-RC2.

With 172.18.10.1 being my local host's wireguard interface's IP address,
I can receive SYN packets, but it does not seem to send any
corresponding SYN/ACK.

=========================
01:26:26.327484 IP 172.18[.10.3.34160 > 172.18.10.1.22: Flags [S], seq
1278197331, win 64860, options [mss 1380,sackOK,TS val 223949166 ecr
0,nop,wscale 7], length 0
01:26:42.708175 IP 172.18.10.3.34160 > 172.18.10.1.22: Flags [S], seq
1278197331, win 64860, options [mss 1380,sackOK,TS val 223965550 ecr
0,nop,wscale 7], length 0
01:27:14.964162 IP 172.18.10.3.34160 > 172.18.10.1.22: Flags [S], seq
1278197331, win 64860, options [mss 1380,sackOK,TS val 223997806 ecr
0,nop,wscale 7], length 0


01:28:34.035384 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
3991744006 ecr 0], length 0
01:28:34.035392 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
3991745042 ecr 0], length 0
01:28:34.036002 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
3991747129 ecr 0], length 0
=========================

ICMP works fine:

=========================
01:53:15.638529 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 0, length 64
01:53:15.638535 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 0, length 64
01:53:16.624443 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 1, length 64
01:53:16.624448 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 1, length 64
01:53:17.672109 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 2, length 64
01:53:17.672115 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 2, length 64
01:53:18.676223 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 3, length 64
01:53:18.676230 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 3, length 64
01:53:19.682131 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 4, length 64
01:53:19.682136 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 4, length 64
=========================

And I can make outbound TCP connections:

=========================
01:50:43.267331 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [S], seq
2119392003, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
1918472905 ecr 0], length 0
01:50:43.415524 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [S.], seq
2602046635, ack 2119392004, win 65535, options [mss 1380,nop,wscale
11,sackOK,TS val 1347987709 ecr 1918472905], length 0
01:50:43.415532 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [.], ack 1,
win 33, options [nop,nop,TS val 1918473053 ecr 1347987709], length 0
01:50:43.415613 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
1:31, ack 1, win 33, options [nop,nop,TS val 1918473053 ecr 1347987709],
length 30
01:50:43.614035 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
1:39, ack 31, win 33, options [nop,nop,TS val 1347987870 ecr
1918473053], length 38
01:50:43.653218 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [.], ack
39, win 33, options [nop,nop,TS val 1918473291 ecr 1347987870], length 0
01:50:43.693420 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
31:1055, ack 39, win 33, options [nop,nop,TS val 1918473331 ecr
1347987870], length 1024
01:50:43.693435 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
1055:1543, ack 39, win 33, options [nop,nop,TS val 1918473331 ecr
1347987870], length 488
01:50:43.818391 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
39:1119, ack 31, win 33, options [nop,nop,TS val 1347988093 ecr
1918473291], length 1080
01:50:43.819870 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
1543:1591, ack 1119, win 33, options [nop,nop,TS val 1918473457 ecr
1347988093], length 48
01:50:43.880995 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [.], ack
1543, win 33, options [nop,nop,TS val 1347988163 ecr 1918473331], length 0
01:50:43.991756 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
1119:1571, ack 1591, win 33, options [nop,nop,TS val 1347988277 ecr
1918473457], length 452
=========================



The tunnel is configured using `wg-quick'. The firewalls are unloaded
for this testing.
 I have made sure to delete the if_wg.ko shipped with FreeBSD, and
rebooted the host before trying this.



And ofcourse, if I switch to userspace Go implementation, everything
works as expected, keeping rest of the configuration same, and with
firewalls enabled.

Thanks!
-- 
Ashish

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210319/c6b0c5cc/attachment.sig>

From ashish.is at lostca.se  Thu Mar 18 20:31:07 2021
From: ashish.is at lostca.se (Ashish)
Date: Fri, 19 Mar 2021 02:01:07 +0530
Subject: Unable to serve TCP connections over wireguard interface on FreeBSD
 13.0-RC2
Message-ID: <2c955be3-7360-cf8c-ad2f-ec1c382242ad@lostca.se>


[apologies, in case you receive duplicate messages]

Hi,

I'm running if_wg kernel module (git revision: 5ef4d3efa691e71) on
FreeBSD 13.0-RC2.

With 172.18.10.1 being my local host's wireguard interface's IP address,
I can receive SYN packets, but it does not seem to send any
corresponding SYN/ACK.

=========================
01:26:26.327484 IP 172.18[.10.3.34160 > 172.18.10.1.22: Flags [S], seq
1278197331, win 64860, options [mss 1380,sackOK,TS val 223949166 ecr
0,nop,wscale 7], length 0
01:26:42.708175 IP 172.18.10.3.34160 > 172.18.10.1.22: Flags [S], seq
1278197331, win 64860, options [mss 1380,sackOK,TS val 223965550 ecr
0,nop,wscale 7], length 0
01:27:14.964162 IP 172.18.10.3.34160 > 172.18.10.1.22: Flags [S], seq
1278197331, win 64860, options [mss 1380,sackOK,TS val 223997806 ecr
0,nop,wscale 7], length 0


01:28:34.035384 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
3991744006 ecr 0], length 0
01:28:34.035392 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
3991745042 ecr 0], length 0
01:28:34.036002 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
3991747129 ecr 0], length 0
=========================

ICMP works fine:

=========================
01:53:15.638529 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 0, length 64
01:53:15.638535 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 0, length 64
01:53:16.624443 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 1, length 64
01:53:16.624448 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 1, length 64
01:53:17.672109 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 2, length 64
01:53:17.672115 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 2, length 64
01:53:18.676223 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 3, length 64
01:53:18.676230 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 3, length 64
01:53:19.682131 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
47881, seq 4, length 64
01:53:19.682136 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
seq 4, length 64
=========================

And I can make outbound TCP connections:

=========================
01:50:43.267331 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [S], seq
2119392003, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
1918472905 ecr 0], length 0
01:50:43.415524 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [S.], seq
2602046635, ack 2119392004, win 65535, options [mss 1380,nop,wscale
11,sackOK,TS val 1347987709 ecr 1918472905], length 0
01:50:43.415532 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [.], ack 1,
win 33, options [nop,nop,TS val 1918473053 ecr 1347987709], length 0
01:50:43.415613 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
1:31, ack 1, win 33, options [nop,nop,TS val 1918473053 ecr 1347987709],
length 30
01:50:43.614035 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
1:39, ack 31, win 33, options [nop,nop,TS val 1347987870 ecr
1918473053], length 38
01:50:43.653218 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [.], ack
39, win 33, options [nop,nop,TS val 1918473291 ecr 1347987870], length 0
01:50:43.693420 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
31:1055, ack 39, win 33, options [nop,nop,TS val 1918473331 ecr
1347987870], length 1024
01:50:43.693435 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
1055:1543, ack 39, win 33, options [nop,nop,TS val 1918473331 ecr
1347987870], length 488
01:50:43.818391 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
39:1119, ack 31, win 33, options [nop,nop,TS val 1347988093 ecr
1918473291], length 1080
01:50:43.819870 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
1543:1591, ack 1119, win 33, options [nop,nop,TS val 1918473457 ecr
1347988093], length 48
01:50:43.880995 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [.], ack
1543, win 33, options [nop,nop,TS val 1347988163 ecr 1918473331], length 0
01:50:43.991756 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
1119:1571, ack 1591, win 33, options [nop,nop,TS val 1347988277 ecr
1918473457], length 452
=========================

The tunnel is configured using `wg-quick'. The firewalls are unloaded
for this testing. I have made sure to delete the if_wg.ko shipped with
FreeBSD, and rebooted the host before trying this.

And ofcourse, if I switch to userspace Go implementation, everything
works as expected, keeping rest of the configuration same, and with
firewalls enabled.

Thanks!
-- 
Ashish

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210319/e05d4594/attachment.sig>

From matthew.poletiek at gmail.com  Fri Mar 19 15:30:28 2021
From: matthew.poletiek at gmail.com (Matthew Poletiek)
Date: Fri, 19 Mar 2021 10:30:28 -0500
Subject: Unable to serve TCP connections over wireguard interface on
 FreeBSD 13.0-RC2
In-Reply-To: <2c955be3-7360-cf8c-ad2f-ec1c382242ad@lostca.se>
References: <2c955be3-7360-cf8c-ad2f-ec1c382242ad@lostca.se>
Message-ID: <CAJhSV8tdX2kEJFZNgzmvgBzz8OOXZvJ0C65QuQs0or3ktpe1yg@mail.gmail.com>

Random thought,

Have you tried adjusting MTU?

Depending on the client/application, I have better luck with something
around 1300.
-------------------------------------------
Matthew Poletiek
303.810.9082
matthew.poletiek at gmail.com
www.matthewpoletiek.com



On Fri, Mar 19, 2021 at 9:09 AM Ashish <ashish.is at lostca.se> wrote:
>
>
> [apologies, in case you receive duplicate messages]
>
> Hi,
>
> I'm running if_wg kernel module (git revision: 5ef4d3efa691e71) on
> FreeBSD 13.0-RC2.
>
> With 172.18.10.1 being my local host's wireguard interface's IP address,
> I can receive SYN packets, but it does not seem to send any
> corresponding SYN/ACK.
>
> =========================
> 01:26:26.327484 IP 172.18[.10.3.34160 > 172.18.10.1.22: Flags [S], seq
> 1278197331, win 64860, options [mss 1380,sackOK,TS val 223949166 ecr
> 0,nop,wscale 7], length 0
> 01:26:42.708175 IP 172.18.10.3.34160 > 172.18.10.1.22: Flags [S], seq
> 1278197331, win 64860, options [mss 1380,sackOK,TS val 223965550 ecr
> 0,nop,wscale 7], length 0
> 01:27:14.964162 IP 172.18.10.3.34160 > 172.18.10.1.22: Flags [S], seq
> 1278197331, win 64860, options [mss 1380,sackOK,TS val 223997806 ecr
> 0,nop,wscale 7], length 0
>
>
> 01:28:34.035384 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
> 2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
> 3991744006 ecr 0], length 0
> 01:28:34.035392 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
> 2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
> 3991745042 ecr 0], length 0
> 01:28:34.036002 IP 172.18.10.2.41905 > 172.18.10.1.22: Flags [S], seq
> 2569759726, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
> 3991747129 ecr 0], length 0
> =========================
>
> ICMP works fine:
>
> =========================
> 01:53:15.638529 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
> 47881, seq 0, length 64
> 01:53:15.638535 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
> seq 0, length 64
> 01:53:16.624443 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
> 47881, seq 1, length 64
> 01:53:16.624448 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
> seq 1, length 64
> 01:53:17.672109 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
> 47881, seq 2, length 64
> 01:53:17.672115 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
> seq 2, length 64
> 01:53:18.676223 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
> 47881, seq 3, length 64
> 01:53:18.676230 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
> seq 3, length 64
> 01:53:19.682131 IP 172.18.10.2 > 172.18.10.1: ICMP echo request, id
> 47881, seq 4, length 64
> 01:53:19.682136 IP 172.18.10.1 > 172.18.10.2: ICMP echo reply, id 47881,
> seq 4, length 64
> =========================
>
> And I can make outbound TCP connections:
>
> =========================
> 01:50:43.267331 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [S], seq
> 2119392003, win 65535, options [mss 1380,nop,wscale 11,sackOK,TS val
> 1918472905 ecr 0], length 0
> 01:50:43.415524 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [S.], seq
> 2602046635, ack 2119392004, win 65535, options [mss 1380,nop,wscale
> 11,sackOK,TS val 1347987709 ecr 1918472905], length 0
> 01:50:43.415532 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [.], ack 1,
> win 33, options [nop,nop,TS val 1918473053 ecr 1347987709], length 0
> 01:50:43.415613 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
> 1:31, ack 1, win 33, options [nop,nop,TS val 1918473053 ecr 1347987709],
> length 30
> 01:50:43.614035 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
> 1:39, ack 31, win 33, options [nop,nop,TS val 1347987870 ecr
> 1918473053], length 38
> 01:50:43.653218 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [.], ack
> 39, win 33, options [nop,nop,TS val 1918473291 ecr 1347987870], length 0
> 01:50:43.693420 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
> 31:1055, ack 39, win 33, options [nop,nop,TS val 1918473331 ecr
> 1347987870], length 1024
> 01:50:43.693435 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
> 1055:1543, ack 39, win 33, options [nop,nop,TS val 1918473331 ecr
> 1347987870], length 488
> 01:50:43.818391 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
> 39:1119, ack 31, win 33, options [nop,nop,TS val 1347988093 ecr
> 1918473291], length 1080
> 01:50:43.819870 IP 172.18.10.1.55541 > 172.18.10.2.22: Flags [P.], seq
> 1543:1591, ack 1119, win 33, options [nop,nop,TS val 1918473457 ecr
> 1347988093], length 48
> 01:50:43.880995 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [.], ack
> 1543, win 33, options [nop,nop,TS val 1347988163 ecr 1918473331], length 0
> 01:50:43.991756 IP 172.18.10.2.22 > 172.18.10.1.55541: Flags [P.], seq
> 1119:1571, ack 1591, win 33, options [nop,nop,TS val 1347988277 ecr
> 1918473457], length 452
> =========================
>
> The tunnel is configured using `wg-quick'. The firewalls are unloaded
> for this testing. I have made sure to delete the if_wg.ko shipped with
> FreeBSD, and rebooted the host before trying this.
>
> And ofcourse, if I switch to userspace Go implementation, everything
> works as expected, keeping rest of the configuration same, and with
> firewalls enabled.
>
> Thanks!
> --
> Ashish
>

From Jason at zx2c4.com  Fri Mar 19 16:15:39 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 19 Mar 2021 10:15:39 -0600
Subject: Unable to serve TCP connections over wireguard interface on
 FreeBSD 13.0-RC2
In-Reply-To: <e1a14dfa-014c-7740-6205-75cd96933dba@lostca.se>
References: <e1a14dfa-014c-7740-6205-75cd96933dba@lostca.se>
Message-ID: <CAHmME9ozQjtg-Rpe9RmwKL6HtDHPkxVQ9d_1EfPQFS5=Zjj4BA@mail.gmail.com>

Hi Ashish,

On Fri, Mar 19, 2021 at 8:06 AM Ashish <ashish.is at lostca.se> wrote:
> I'm running if_wg kernel module (git revision: 5ef4d3efa691e71) on
> FreeBSD 13.0-RC2.
>
> With 172.18.10.1 being my local host's wireguard interface's IP address,
> I can receive SYN packets, but it does not seem to send any
> corresponding SYN/ACK.

Huh, that's curious. I'll look into it and play around. One
peculiarity I noticed in this thing is that it calls the ip_input
function directly, which other drivers don't seem to do.

Regards,
Jason

From Jason at zx2c4.com  Fri Mar 19 16:48:44 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 19 Mar 2021 10:48:44 -0600
Subject: Unable to serve TCP connections over wireguard interface on
 FreeBSD 13.0-RC2
In-Reply-To: <CAHmME9ozQjtg-Rpe9RmwKL6HtDHPkxVQ9d_1EfPQFS5=Zjj4BA@mail.gmail.com>
References: <e1a14dfa-014c-7740-6205-75cd96933dba@lostca.se>
 <CAHmME9ozQjtg-Rpe9RmwKL6HtDHPkxVQ9d_1EfPQFS5=Zjj4BA@mail.gmail.com>
Message-ID: <CAHmME9pnnAY-ugHRbFAVkVukKfgxq3s0iqox4aADGiBWVh7XnA@mail.gmail.com>

Hi Ashish,

Fixed: https://git.zx2c4.com/wireguard-freebsd/commit/?id=bb59a61785322a086dfc437c51e7cbcd918a5241

Thanks for the report.

Jason

From frank at harz.behrens.de  Fri Mar 19 16:57:01 2021
From: frank at harz.behrens.de (Frank Behrens)
Date: Fri, 19 Mar 2021 17:57:01 +0100
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
Message-ID: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>

Hello Jason, hello community,

although I regret the recent removal of FreeBSD kernel driver I can live 
with the present development model.

With the current sources in the external repository I could create a 
working VPN for the first time with my Android phone. It works well, 
thanks to all contributors. The setup was done only with ifconfig(8), I 
have the now removed parts still in place. :-)

For my setup I needed a different route for the encapsulated packets and 
so I implemented the missing parts. With this message I give that part 
to the community (matching the existing BSD-2-Clause-FreeBSD license).
For the sake of simplicity I created an own branch on github, the commit 
is 
https://github.com/frbehrens/wireguard-freebsd/commit/f0445be7b5b30a98da11bf2e209739a2155a59bb 
or use for direct patch download:
https://github.com/frbehrens/wireguard-freebsd/commit/f0445be7b5b30a98da11bf2e209739a2155a59bb.patch

Kind regards,
 ??? Frank

-- 
Frank Behrens
Osterwieck, Germany


From Jason at zx2c4.com  Fri Mar 19 17:06:21 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 19 Mar 2021 11:06:21 -0600
Subject: [PATCH] Fix build on FreeBSD 13 after removal from base
In-Reply-To: <75ddd07a-8d31-4938-8480-540f1996c9ad@yggdrasil.evilham.com>
References: <75ddd07a-8d31-4938-8480-540f1996c9ad@yggdrasil.evilham.com>
Message-ID: <CAHmME9rrBuK1oFwmrFtfhwsM95-MRKzW8L3DysCGS3xCnOFb1w@mail.gmail.com>

Thanks for the patch. I addressed this slightly differently here:

https://git.zx2c4.com/wireguard-freebsd/commit/?id=519e70d5fe88f1ae3c6d2318b22ecf927953fd02

I also trimmed those structs down a bit, as the latter members differ
between 13 and 14.

From Jason at zx2c4.com  Fri Mar 19 17:35:33 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 19 Mar 2021 11:35:33 -0600
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
Message-ID: <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>

Hey Frank,

Thanks for the patch. That looks terrific. One question, though:

Right now we have the `wg set wg0 fwmark ...` mapped to
SO_USER_COOKIE, as I'm sure you saw there. But maybe FIB would be a
better thing to use for that? We could adjust wireguard-go to do the
same with the tuntap ioctl.

Jason

From Jason at zx2c4.com  Fri Mar 19 17:38:25 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 19 Mar 2021 11:38:25 -0600
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
Message-ID: <CAHmME9qB6SSuLagNV3gvVscxLJm=TuFoqk9eb1E0iFhHtohigw@mail.gmail.com>

Hi again,

As well, you can now do:

git push git at git.zx2c4.com:wireguard-freebsd master:fb/whatever-you-want

In other words, you have push access to all branches beginning with fb/ .

Poke me on IRC (I'm zx2c4) there if you want to chat about dev.

Jason

From Jason at zx2c4.com  Fri Mar 19 18:56:34 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 19 Mar 2021 12:56:34 -0600
Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20210319 is available
Message-ID: <mailman.1.1616180208.269.wireguard@lists.zx2c4.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

An experimental snapshot, v0.0.20210319, of WireGuard for FreeBSD has been
been tagged in the git repository.

At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain security issues. We gladly
welcome your testing and bug reports, but do keep in mind that this code
is new, so some caution should be exercised at the moment for using it
in mission critical environments.

== Changes ==

  * if_wg: use our own taskqgroup
  
  This removes the dependency on iflib entirely.
  
  * compat: backport to FreeBSD 12.2
  * compat: backport to FreeBSD 12.1
  * compat: backport properly to 13
  * if_wg: cleanup timeout_t usage
  
  This is now running on 13.0 RC3, 12.2, 12.1.
  
  * if_wg: fix malloc overflows
  
  These should have been fixed during our initial pass but somehow
  weren't. Good thing we have more time to work on this.
  
  * if_wg: dispatch packets using netisr
  * if_wg: mark as point to point
  
  These fix up some network particulars that bring the inbound packet flow a bit
  more inline with what other drivers, like GRE or tuntap do. In particular, it
  should now be possible to listen on incoming TCP sockets.

The source repository is available at the usual location:
  git clone https://git.zx2c4.com/wireguard-freebsd

This snapshot is available in compressed tarball form:
  https://git.zx2c4.com/wireguard-freebsd/snapshot/wireguard-freebsd-0.0.20210319.tar.xz
  SHA2-256: 96836d90a8daad863ccd9503e3bad4ca6c4c25df4892fc1e55b7a8f7b03afbcd

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmBU84AQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4Drvt3EAC9ZMmkCeePRV6m4cTxnGYzCsaaqhXBgMKP
qqsB/YMe6d7gWgDSARBW+49Nql1EG+V1mYP8+Cn3hBbCNE76vR+EuDs8d7xA/lqE
2KA44gX8GTbfZJHRCtPsh/la96OARXPPT4OPyc86mY1GlJc3Xg5KxV24PH4QFqEA
AFnEvE91/lc+aZxkhuZ2mLYhz9eHwdEIHUfGm4cK8D6UM1Jvt8q3I8TOYA+WTbTD
30sQz4ymMtfE89gH+ExCRpE5qrRxMm9AFP4N2A5CNf3tGLf3ptXW2prLo2u+UymP
GSugEDHbyGjx7APtYCEv5uqfGBRpiv/lnmC5iv3Z1V8GMKqB4kPcxPJwQEvwOVhr
Of7CefHdpyuMHr3jWH+dMc4ZWNvKhJ42wZbb/A+yojM4t3ZyEBirlYHJ0Ieb/8IY
ZAvXEI16L4pIikcWbOR0u+faE4+YtO1F2H3eTxXEuyPCcMnPN7iatqXvwuPNjx/w
/KaXtPXdi5gNIWLjohNx0nO/guC/hz7JiIs6A9N+0JjmyzElKwzDou4+Us99QNyh
iwGi0OJmuSE1nEOZ4H9lwGx1CJlEB2aflVpqe8VBEFn1XpotQT42e84UpqHAAM7p
L97KJkNFJcQpQIG29C2nu8cGKqvM2MguNwTjSUBYy3Q/eZqWwyxE3GFwbvcMMc1n
Vs6DlYtxWA==
=4RS0
-----END PGP SIGNATURE-----

From Jason at zx2c4.com  Fri Mar 19 19:37:19 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 19 Mar 2021 13:37:19 -0600
Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20210319 is available
In-Reply-To: <201245f5d3e86a58@lists.zx2c4.com>
References: <201245f5d3e86a58@lists.zx2c4.com>
Message-ID: <CAHmME9o+2507x9ExtzSyP93GiaSMqkd4co3yCmqOkJ_Zp4+kfw@mail.gmail.com>

Good news! This is now in ports as net/wireguard-kmod. That means it
should eventually be built into a package too:

    # pkg install wireguard-kmod

From ashish.is at lostca.se  Fri Mar 19 20:11:34 2021
From: ashish.is at lostca.se (Ashish SHUKLA)
Date: Sat, 20 Mar 2021 01:41:34 +0530
Subject: Unable to serve TCP connections over wireguard interface on
 FreeBSD 13.0-RC2
In-Reply-To: <CAHmME9pnnAY-ugHRbFAVkVukKfgxq3s0iqox4aADGiBWVh7XnA@mail.gmail.com>
References: <e1a14dfa-014c-7740-6205-75cd96933dba@lostca.se>
 <CAHmME9ozQjtg-Rpe9RmwKL6HtDHPkxVQ9d_1EfPQFS5=Zjj4BA@mail.gmail.com>
 <CAHmME9pnnAY-ugHRbFAVkVukKfgxq3s0iqox4aADGiBWVh7XnA@mail.gmail.com>
Message-ID: <a70f3baa61b4cd90737e6ba689223f6a@lostca.se>

On 2021-03-19 22:18, Jason A. Donenfeld wrote:
> Hi Ashish,
> 
> Fixed:
> https://git.zx2c4.com/wireguard-freebsd/commit/?id=bb59a61785322a086dfc437c51e7cbcd918a5241
> 
> Thanks for the report.
> 
> Jason

Seems to work as expected now, thank you.

--
Ashish

?There was truth and there was untruth, and if you clung to the truth 
even against the whole world, you were not mad.?
        -- George Orwell, "Nineteen Eighty-Four"

From Jason at zx2c4.com  Sat Mar 20 02:33:55 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 19 Mar 2021 20:33:55 -0600
Subject: Wireguard Windows ARM64 Build 21327
In-Reply-To: <CAHmME9qvexiP9ZFLMJfFEQEnaYHFZkPWmBUBwzdTs7Zov1poCA@mail.gmail.com>
References: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>
 <CAHmME9q5HJ0QJMzqGBPjr-c4YSBcn3=JWjJB6BRAQtvzb02t6A@mail.gmail.com>
 <kvwelbya-mAZJ2wfpt2vqF1O0GE7BwijqjtQjshHnNMooW7y_J8W6BgMKM65sGgZEWZQx7Zr4uejYiDkfL07ckiwZKqt2DR7BNrnJtXUsHs=@protonmail.com>
 <CAHmME9qvexiP9ZFLMJfFEQEnaYHFZkPWmBUBwzdTs7Zov1poCA@mail.gmail.com>
Message-ID: <CAHmME9qvh8PBGX-0mrnHDhxMF_+Do0JzjUf0L+hJkeiNfViqCw@mail.gmail.com>

Hi Bradley,

The hardware I ordered finally came and I was able to reproduce and
then fix the bug, which was in the Go runtime.

The bug report I filed is here: https://github.com/golang/go/issues/45138

As of writing, the fix I've submitted is here:
https://go-review.googlesource.com/c/go/+/303273/
But that fix could wind up being wrong and replaced with something
else. Either way, as soon as that or something else is merged, I'll
cut a new release with the fix in it.

Thanks again for the report.

Regards,
Jason

From bradsoto at protonmail.com  Sat Mar 20 05:39:12 2021
From: bradsoto at protonmail.com (Bradley Saulteaux)
Date: Sat, 20 Mar 2021 05:39:12 +0000
Subject: Wireguard Windows ARM64 Build 21327
In-Reply-To: <CAHmME9qvh8PBGX-0mrnHDhxMF_+Do0JzjUf0L+hJkeiNfViqCw@mail.gmail.com>
References: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>
 <CAHmME9q5HJ0QJMzqGBPjr-c4YSBcn3=JWjJB6BRAQtvzb02t6A@mail.gmail.com>
 <kvwelbya-mAZJ2wfpt2vqF1O0GE7BwijqjtQjshHnNMooW7y_J8W6BgMKM65sGgZEWZQx7Zr4uejYiDkfL07ckiwZKqt2DR7BNrnJtXUsHs=@protonmail.com>
 <CAHmME9qvexiP9ZFLMJfFEQEnaYHFZkPWmBUBwzdTs7Zov1poCA@mail.gmail.com>
 <CAHmME9qvh8PBGX-0mrnHDhxMF_+Do0JzjUf0L+hJkeiNfViqCw@mail.gmail.com>
Message-ID: <LPfKC3Tqkdr8gYTfUyIox24RcE7O3rmYx4FbE-Js2TAQDlLFY-nEaj2PBum1YoZjv6oHyhPGQRDVOL0wNE2wD7BildydzjZ2d0qNVA8WhAs=@protonmail.com>

Thank you very much!

??????? Original Message ???????
On Friday, March 19, 2021 8:33 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:

> Hi Bradley,
>
> The hardware I ordered finally came and I was able to reproduce and
> then fix the bug, which was in the Go runtime.
>
> The bug report I filed is here: https://github.com/golang/go/issues/45138
>
> As of writing, the fix I've submitted is here:
> https://go-review.googlesource.com/c/go/+/303273/
> But that fix could wind up being wrong and replaced with something
> else. Either way, as soon as that or something else is merged, I'll
> cut a new release with the fix in it.
>
> Thanks again for the report.
>
> Regards,
> Jason



From frank at harz.behrens.de  Sat Mar 20 17:05:32 2021
From: frank at harz.behrens.de (Frank Behrens)
Date: Sat, 20 Mar 2021 18:05:32 +0100
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
 <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
Message-ID: <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>

Hi Jason,

thanks for your response.

Am 19.03.2021 schrieb Jason A. Donenfeld:
> In other words, you have push access to all branches beginning with fb/ .
That works, thanks. Meanwhile I pushed my branch to fb/fib.

> Right now we have the `wg set wg0 fwmark ...` mapped to
> SO_USER_COOKIE, as I'm sure you saw there. But maybe FIB would be a
> better thing to use for that? We could adjust wireguard-go to do the
> same with the tuntap ioctl.
I believe we have different, orthogonal things:

1. The selection of routing table (fib) for received, decrypted packets.
-> Already implemented in wg_deliver_in() #2098 and controlled
by "ifconfig wg0 fib 1"

2. The selection of routing table for outgoing, encrypted packets.
-> That is addressed by my patch and controlled by
"ifconfig wg0 tunnelfib 1". Maybe wg(8) should receive also
an option for that purpose, if other OS use equivalent functions.

3. The setting of special marks, useable in packet filter/firewall
processing. I guess, that is the meaning for "wg.. fwmark". I'm not
sure, how best to implement that for FreeBSD. For ipfw(4) there is some
functionality using socket cookies, as already implemented. For pf(4)
packet filter the documentation mentions mbuf_tags(9). Apparently
we need some input from a FreeBSD packet filter developer.

Kind regards,
 ??? Frank

-- 
Frank Behrens
Osterwieck, Germany


From franco at opnsense.org  Sat Mar 20 18:59:16 2021
From: franco at opnsense.org (Franco Fichtner)
Date: Sat, 20 Mar 2021 19:59:16 +0100
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
 <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
 <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
Message-ID: <B71D1758-3EDE-4844-99FC-7D6BD125D0ED@opnsense.org>

Hi Frank,

> On 20. Mar 2021, at 6:05 PM, Frank Behrens <frank at harz.behrens.de> wrote:
> 
> 3. The setting of special marks, useable in packet filter/firewall
> processing. I guess, that is the meaning for "wg.. fwmark". I'm not
> sure, how best to implement that for FreeBSD. For ipfw(4) there is some
> functionality using socket cookies, as already implemented. For pf(4)
> packet filter the documentation mentions mbuf_tags(9). Apparently
> we need some input from a FreeBSD packet filter developer.

In pf(4) the tags are stored using mtag and that's reachable through
the kernel only for direct tagging (normally it matches through ruleset
and applies tags to packets in fly-by), although it is difficult to look
up the tag name to tag integer from static functions inside pf_ioctl.c
and keeping the index in sync with the tags that could change when the
ruleset changes, see pf_tag_packet() in pf.c for low level tagging using
the tag integer translated from the tag name during the last ruleset apply.


Cheers,
Franco

From bjoern at reldeif.de  Sun Mar 21 21:24:52 2021
From: bjoern at reldeif.de (=?UTF-8?Q?Bj=c3=b6rn_Fiedler?=)
Date: Sun, 21 Mar 2021 22:24:52 +0100
Subject: Android/GoBackend: Wrong Src IP
Message-ID: <a2b1d031-029c-d71b-ff59-e7d1442af6a7@reldeif.de>

Hi,

I'd like to report some kind of behavior from which I think it is a bug of the Android App with go backend.


The Scenario:
My android phone should participate in two private networks with distinct IP ranges, subnets and clients. As the android app is restricted to one interface at a time, the single config contains the settings for both private nets.

Server A:
[Interface]
Address = 10.14.0.221/24
ListenPort = 56345
PrivateKey = ...

[Peer]
AllowedIPs = 10.14.0.13
PublicKey = ...


Server B:
[Interface]
Address = 10.200.200.2/24
ListenPort = 37699
PrivateKey = ...

[Peer]
PublicKey = ...
AllowedIPs = 10.200.200.13/32



Android phone:
[Interface]
PrivateKey = ...
Address = 10.200.200.13/24
Address = 10.14.0.13/24
ListenPort = 6677


[Peer]
AllowedIPs = 10.200.200.0/24
Endpoint = server_a.example.com:56345
PublicKey = ...


[Peer]
AllowedIPs = 10.14.0.0/24
Endpoint = server_b.example.com:37699
PublicKey = ...



The Problem:
Issue a `ping 10.200.200.2` via termux works as expected.
Issue a `ping 10.14.0.221` via termux results in 100% packet loss.


The ip address assignment and routing tables of my phone seem to be as I would expect them
$ ip route
10.14.0.0/24 dev tun0 proto kernel scope link src 10.14.0.13
10.200.200.0/24 dev tun0 proto kernel scope link src 10.200.200.13
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.151

$ ip address? show tun0
42: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
 ??? link/none
 ??? inet 10.200.200.13/24 scope global tun0
 ?????? valid_lft forever preferred_lft forever
 ??? inet 10.14.0.13/24 scope global tun0:1
 ?????? valid_lft forever preferred_lft forever
 ??? inet6 fe80::ee0a:a411:b6b2:a911/64 scope link stable-privacy
 ?????? valid_lft forever preferred_lft forever


The kernel logs from server A shows the problem:
[309387.725202] wireguard: wg0: Packet has unallowed src IP (10.200.200.13) from peer 13 (192.168.2.151:6677)

It seems as if the wrong address is used as source addres by the android app or go backend. I've tested the same config on a linux machine using the wireguard-go userspace implementation but it worked correctly. Hence I would assume it is some kind of interworking problem of the android components.
Switching the two addresses in the interface section results in the same behaviour but inverted. It always uses the first address as source address.
The problem is not limited to ping but seems to affect all apps and protocols (tested http, ssh, ping).

App version:
WireGuard for Android v1.0.20210211
Go userspace backend v0.0.20201118
Installed via google play

Android 10 QKQ1.191215.002
Kernel 4.14.117-perf-ge9e6b4f


If you need more infos or my help for reproducing, let me know.

Thank you in advance,
Bj?rn

From Jason at zx2c4.com  Mon Mar 22 17:43:56 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 22 Mar 2021 11:43:56 -0600
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
 <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
 <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
Message-ID: <CAHmME9qaMcd0R1zvFy+ZyW4a1vmX1bE_Rxf4WFgau4UTdEi7hQ@mail.gmail.com>

Hi Frank,

On Sat, Mar 20, 2021 at 11:15 AM Frank Behrens <frank at harz.behrens.de> wrote:
>
> Hi Jason,
>
> thanks for your response.
>
> Am 19.03.2021 schrieb Jason A. Donenfeld:
> > In other words, you have push access to all branches beginning with fb/ .
> That works, thanks. Meanwhile I pushed my branch to fb/fib.
>
> > Right now we have the `wg set wg0 fwmark ...` mapped to
> > SO_USER_COOKIE, as I'm sure you saw there. But maybe FIB would be a
> > better thing to use for that? We could adjust wireguard-go to do the
> > same with the tuntap ioctl.
> I believe we have different, orthogonal things:
>
> 1. The selection of routing table (fib) for received, decrypted packets.
> -> Already implemented in wg_deliver_in() #2098 and controlled
> by "ifconfig wg0 fib 1"
>
> 2. The selection of routing table for outgoing, encrypted packets.
> -> That is addressed by my patch and controlled by
> "ifconfig wg0 tunnelfib 1". Maybe wg(8) should receive also
> an option for that purpose, if other OS use equivalent functions.
>
> 3. The setting of special marks, useable in packet filter/firewall
> processing. I guess, that is the meaning for "wg.. fwmark". I'm not
> sure, how best to implement that for FreeBSD. For ipfw(4) there is some
> functionality using socket cookies, as already implemented. For pf(4)
> packet filter the documentation mentions mbuf_tags(9). Apparently
> we need some input from a FreeBSD packet filter developer.

It looks like user_cookie is independently useful for use in ipfw, so
I'll keep fwmark mapped to that. But your tunnelfib patch is _also_
useful, so I'll apply this patch.

Some bugs/questions, though:

+static void
+wg_socket_setfib(struct wg_softc *sc)
+{
+ struct wg_socket *so = &sc->sc_socket;
+ struct socket *so4, *so6;
+ struct sockopt sopt;
+ int rc;
+
+ so4 = atomic_load_ptr(&so->so_so4);
+ so6 = atomic_load_ptr(&so->so_so6);

These are epoch-protected members. So the line above that should have
NET_EPOCH_ASSERT().

+ if (so4) {
+ rc = sosetopt(so4, &sopt);
+ MPASS(rc == 0);
+ }
+ if (so6) {
+ rc = sosetopt(so6, &sopt);
+ MPASS(rc == 0);
+ }

Rather than MPASS, this error should be passed back to the caller and
reported back to userspace, in the same way that we account for errors
with socket binding.

+ case SIOCSTUNFIB:
+ if ((ret = priv_check(curthread, PRIV_NET_SETIFFIB)) != 0)
+ break;

This priv check should be relative to our stored creds that control
the socket right? There are some jail considerations to think about
here.

+ if (ifr->ifr_fib >= rt_numfibs) {
+ ret = EINVAL;
+ } else {
+ sc->sc_fibnum = ifr->ifr_fib;
+ wg_socket_setfib(sc);
+ }

There are two ways to implement this. Either we check for 0 <= ifr_fib
< rt_numfibs, and then directly assign it to so->so_fibnum, like we do
for user_cookie, and avoid sosockopt. This sounds simplest and I
wouldn't mind doing that. Or we use sosockopt, but the bounds testing
remains in sosockopt and not duplicated here, and we rely on
wg_socket_setfib bubbling the error back up. Let's pick one of these
approaches, rather than combining them.


struct wg_softc {
LIST_ENTRY(wg_softc) sc_entry;
struct ifnet *sc_ifp;
int sc_flags;
+ u_int sc_fibnum;

Shouldn't this be added to `struct wg_socket`, alongside the
so_user_cookie member there, and managed in the same way?

Jason

From Jason at zx2c4.com  Mon Mar 22 18:14:52 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 22 Mar 2021 12:14:52 -0600
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <CAHmME9qaMcd0R1zvFy+ZyW4a1vmX1bE_Rxf4WFgau4UTdEi7hQ@mail.gmail.com>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
 <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
 <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
 <CAHmME9qaMcd0R1zvFy+ZyW4a1vmX1bE_Rxf4WFgau4UTdEi7hQ@mail.gmail.com>
Message-ID: <CAHmME9r13tPji0Guw3_Q8k4grh046RkSccPLbEVAasKQ=BNkVw@mail.gmail.com>

Applied to git with some small modifications:

https://git.zx2c4.com/wireguard-freebsd/commit/?id=0a5c6abdfaa1f4f09269a222c1720e2ff3b8aa02

This will be in the next snapshot. And feel free to push other stuff
up to the repo as you feel is useful.

Jason

From Jason at zx2c4.com  Tue Mar 23 02:32:54 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 22 Mar 2021 20:32:54 -0600
Subject: Wireguard Windows ARM64 Build 21327
In-Reply-To: <LPfKC3Tqkdr8gYTfUyIox24RcE7O3rmYx4FbE-Js2TAQDlLFY-nEaj2PBum1YoZjv6oHyhPGQRDVOL0wNE2wD7BildydzjZ2d0qNVA8WhAs=@protonmail.com>
References: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>
 <CAHmME9q5HJ0QJMzqGBPjr-c4YSBcn3=JWjJB6BRAQtvzb02t6A@mail.gmail.com>
 <kvwelbya-mAZJ2wfpt2vqF1O0GE7BwijqjtQjshHnNMooW7y_J8W6BgMKM65sGgZEWZQx7Zr4uejYiDkfL07ckiwZKqt2DR7BNrnJtXUsHs=@protonmail.com>
 <CAHmME9qvexiP9ZFLMJfFEQEnaYHFZkPWmBUBwzdTs7Zov1poCA@mail.gmail.com>
 <CAHmME9qvh8PBGX-0mrnHDhxMF_+Do0JzjUf0L+hJkeiNfViqCw@mail.gmail.com>
 <LPfKC3Tqkdr8gYTfUyIox24RcE7O3rmYx4FbE-Js2TAQDlLFY-nEaj2PBum1YoZjv6oHyhPGQRDVOL0wNE2wD7BildydzjZ2d0qNVA8WhAs=@protonmail.com>
Message-ID: <CAHmME9quO_Do25BaGOHX3Vdh3PPYRUeQR+U490HMYUpwemJKow@mail.gmail.com>

Hi again Bradley,

https://github.com/golang/go/commit/78afca22c9485dbd44da3b909866bbb9c1eaf440
was committed, and so WireGuard for Windows v0.3.9 was released. You
said that you downgraded to some earlier arm32 version, so I imagine
you've just been ignoring the update notification. Try updating now,
and see if things go well.

Jason

From frank at harz.behrens.de  Tue Mar 23 05:51:23 2021
From: frank at harz.behrens.de (Frank Behrens)
Date: Tue, 23 Mar 2021 06:51:23 +0100
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <CAHmME9r13tPji0Guw3_Q8k4grh046RkSccPLbEVAasKQ=BNkVw@mail.gmail.com>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
 <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
 <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
 <CAHmME9qaMcd0R1zvFy+ZyW4a1vmX1bE_Rxf4WFgau4UTdEi7hQ@mail.gmail.com>
 <CAHmME9r13tPji0Guw3_Q8k4grh046RkSccPLbEVAasKQ=BNkVw@mail.gmail.com>
Message-ID: <89952f1f-5296-7f87-9345-0f5c087ee3ae@harz.behrens.de>

Hi Jason!

Am 22.03.2021 um 19:14 schrieb Jason A. Donenfeld:
> Applied to git with some small modifications:
>
> https://git.zx2c4.com/wireguard-freebsd/commit/?id=0a5c6abdfaa1f4f09269a222c1720e2ff3b8aa02
Thanky you! That looks very good.

-- 
Frank Behrens
Osterwieck, Germany


From laura.zelenku at wandera.com  Tue Mar 23 09:47:08 2021
From: laura.zelenku at wandera.com (Laura Zelenku)
Date: Tue, 23 Mar 2021 10:47:08 +0100
Subject: Handshake state collision between parralel RoutineHandshake
 threads
In-Reply-To: <6B92ECA6-AEC9-42F2-AB98-013CBB70691C@wandera.com>
References: <27D86318-AED9-49EC-94EE-1FFC806533DC@wandera.com>
 <CAHmME9oOKvMqvSw_CrjhiWU+R60AEVxLYzoaC8W7F7D5vWgWvA@mail.gmail.com>
 <92B58443-8904-417B-A866-7BD2C6240B42@wandera.com>
 <6B92ECA6-AEC9-42F2-AB98-013CBB70691C@wandera.com>
Message-ID: <2F538518-C3E5-4418-910F-E8EBF7686C19@wandera.com>

Or can we at least lower log level of "Failed to create response message? if it is not problem? The error is really disturbing and as you wrote one of the handshakes is processed.

> On 16. 3. 2021, at 15:03, Laura Zelenku <laura.zelenku at wandera.com> wrote:
> 
> Still struggling with this issue. Running RoutineHandshake in single instance will help. Remember there is shared resource ?peer.handshake.state?. Even the resource is per peer there are two directions (upstream/downstream) that can fight for this resource and write it?s own value.
> 
> Index: device/receive.go
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===================================================================
> --- device/receive.go	(revision 5f0c8b942d93be6ac36a156c0ba44c86c3698f91)
> +++ device/receive.go	(date 1615902577604)
> @@ -10,6 +10,7 @@
> 	"encoding/binary"
> 	"errors"
> 	"net"
> +	"runtime"
> 	"sync"
> 	"sync/atomic"
> 	"time"
> @@ -239,7 +240,9 @@
> func (device *Device) RoutineHandshake() {
> 	defer func() {
> 		device.log.Verbosef("Routine: handshake worker - stopped")
> -		device.queue.encryption.wg.Done()
> +		for i := 0; i < runtime.NumCPU(); i++ {
> +			device.queue.encryption.wg.Done()
> +		}
> 	}()
> 	device.log.Verbosef("Routine: handshake worker - started")
> 
> Index: device/device.go
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===================================================================
> --- device/device.go	(revision 5f0c8b942d93be6ac36a156c0ba44c86c3698f91)
> +++ device/device.go	(date 1615902577566)
> @@ -305,12 +305,12 @@
> 
> 	cpus := runtime.NumCPU()
> 	device.state.stopping.Wait()
> -	device.queue.encryption.wg.Add(cpus) // One for each RoutineHandshake
> +	device.queue.encryption.wg.Add(cpus)
> 	for i := 0; i < cpus; i++ {
> 		go device.RoutineEncryption()
> 		go device.RoutineDecryption()
> -		go device.RoutineHandshake()
> -	}
> +	}
> +	go device.RoutineHandshake()
> 
> 	device.state.stopping.Add(1)      // RoutineReadFromTUN
> 	device.queue.encryption.wg.Add(1) // RoutineReadFromTUN
> 
> 
>> On 1. 3. 2021, at 15:08, Laura Zelenku <laura.zelenku at wandera.com> wrote:
>> 
>> Hi Jason,
>> I?ll try to explain the issue.
>> 
>> For incomming hanshake, the `handshake.state` is changing in the following way:
>> 1. set state handshakeInitiationConsumed
>> 2. check the state is handshakeInitiationConsumed otherwise "handshake initiation must be consumed first? error
>> 3. set state handshakeResponseCreated
>> 4. check the state is handshakeResponseCreated, otherwise "invalid state for keypair derivation? error
>> 5. set state handshakeZeroed
>> 
>> For outgoing handshake the `handshake.state` is changing:
>> 1. set state handshakeInitiationCreated
>> 2. <sending handshake and waiting for response>
>> 3. check the state is handshakeInitiationCreated, otherwise skip the packet
>> 4. set state handshakeResponseConsumed
>> 5. check the state is handshakeResponseConsumed, otherwise "invalid state for keypair derivation? error
>> 6. set state handshakeZeroed
>> 
>> Usually only ?client? is sending handshake initiations and the ?server? responding. But in case some delay (e.g. cause by some network issues mainly for mobile devices) the ?server? can start sending handshake initiations (expiredNewHandshake or expiredRetransmitHandshake timers). In this time the client and server are sending hanshake initiations against each other. "go device.RoutineHandshake()? is running in multiple threads. `handshake.state` is defined per peer. Two threads (RoutineHandshake) can process both handshakes (incomming, outgoing) in the same time and these threads are working with shared resource, handshake.state. Because the routine is expecting state that was set before and the second thread can modify the state, the routine can fail on checking the expected handshake.state.
>> This is happening to us. We are getting error "handshake initiation must be consumed first?. handshakeInitiationConsumed is expected but handshakeZeroed is actually set (set by different thread). The error is logged on error level (Failed to create response message).
>> 
>> Hope this will help to understand the issue well.
>> 
>> Laura
>> 
>> 
>>> On 25 Feb 2021, at 12:23, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>>> 
>>> Hi Laura,
>>> 
>>> I'm not sure this is actually a problem. The latest handshake message
>>> should probably win the race. I don't see state machine or data
>>> corruption here, but just one handshake interrupting another, which is
>>> par for the course with WireGuard.
>>> 
>>> Or have I overlooked something important in the state machine implementation?
>>> 
>>> Jason
>> 
> 


-- 
*IMPORTANT NOTICE*: This email, its attachments and any rights attaching 
hereto are confidential and intended exclusively for the person to whom the 
email is addressed. If you are not the intended recipient, do not read, 
copy, disclose or use the contents in any way. Wandera accepts no liability 
for any loss, damage or consequence resulting directly or indirectly from 
the use of this email and attachments.

From facboy at gmail.com  Tue Mar 23 11:01:32 2021
From: facboy at gmail.com (Christopher Ng)
Date: Tue, 23 Mar 2021 11:01:32 +0000
Subject: Problems with Windows client over PulseSecure VPN
In-Reply-To: <CAHmME9qtPLOTaY3UzyCY1C6guVZXvJjXHeFwT8=94d=Zpjj=Tw@mail.gmail.com>
References: <9f621ce6-ec3d-0641-c359-756d0ad36f65@gmail.com>
 <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com>
 <CAHmME9qtPLOTaY3UzyCY1C6guVZXvJjXHeFwT8=94d=Zpjj=Tw@mail.gmail.com>
Message-ID: <CAN5wt5poiJbOAfe+_VQpu=+6V8dLDiFDVyhUFNbad5NEd9YFfA@mail.gmail.com>

this sort of works for me too, the only problem is 'wg set' never
returns (even on the CLI) so the tunnel activation hangs in
'activating' waiting for it to return, which it never does.  this is
on 0.3.9 in windows

On Wed, 3 Mar 2021 at 10:56, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hey Peter,
>
> I had a strange idea for how to fix this without requiring
> recompilation or removal of that code.
>
> 1) Enable DangerousScriptExecution:
> https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution
>
> 2) Add a PostUp line to your [Interface] section:
>
> PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0
>
> 3) Try it and tell me if it works?
>
> Regards,
> Jason

From Jason at zx2c4.com  Tue Mar 23 19:03:14 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 23 Mar 2021 13:03:14 -0600
Subject: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20210323 is available
Message-ID: <mailman.2.1616526508.269.wireguard@lists.zx2c4.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

An experimental snapshot, v0.0.20210323, of WireGuard for FreeBSD has been
been tagged in the git repository.

At this time this code is new, unvetted, possibly buggy, and should be
considered "experimental". It might contain security issues. We gladly
welcome your testing and bug reports, but do keep in mind that this code
is new, so some caution should be exercised at the moment for using it
in mission critical environments.

== Changes ==

  * if_wg: do not check for null M_NOWAIT return
  * compat: backport callout_func_t to 12.1
  * wg_noise: ensure non-zero'd handshakes have a valid local index
  * if_wg: fix decryption failures on jumbo ingress
  
  Numerous correctness fixes.
  
  * if_wg: implement selection of FIB (routing table) for tunneled packets
  
  It's now possible to run `ifconfig wg0 tunnelfib 7` or the like.
  
  * if_wg: drop pointtopoint flag
  * if_wg: disable llv6
  
  Set better flags for the interface to reflect how its routing actually works.
  Note that this will need a patch to wg-quick(8), since we're leaving
  point-to-point mode. A new release of wireguard-go will be made to with the
  same change.

This snapshot contains commits from: Jason A. Donenfeld, Matt Dunwoodie, and 
Frank Behrens.

The source repository is available at the usual location:
  git clone https://git.zx2c4.com/wireguard-freebsd

This snapshot is available in compressed tarball form:
  https://git.zx2c4.com/wireguard-freebsd/snapshot/wireguard-freebsd-0.0.20210323.tar.xz
  SHA2-256: 9e37f330cea71974d9ac0a7f177d7c4d3252faaee574eb896ff553c55790f46d

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmBaO1YQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrgwkEAC6yIjz759hctDkwnrpEaKXrYUNCSV7hjcN
1jIP6AtnV4cgDVQ0v2yvMtkWhqovdGlFK/2Db+3zeEc9cKRarvCPBfQ1TDTKb899
NkyNVuxgXduCha3wVJyWLQGO3ry5i0765H6Wxyo52Jjb8aBWqh8VRauF+hfljbfg
BfiuLMMXXmPyhnuzlAc2p3G9SMV6NDMeGGs5ipjKk3fqBzIe4qvjVWA3Y41P4rjJ
89rXKWUrcRMgnb3/UOS/43+Q7b/9EeLfMZgHN4OUqpRcr9rJA5IED+JotcydpL5p
ar6mcurltQFL8NzE0b8AXcO8x0fB6CYUCWJDISK2neXCsonltcnGmTuZAYA7HzL1
NqA5b5/7pTqNIym/gzdummYDqwTSjtTm4/EOdac1k0z9nAoo7kDtatZTD0d6a7sP
jbM27DdwtEgIDp5aIaxkplI0x+5QRqfg/A+PjjSvRG6V8o/NpQWO2kJfu5Pcm4Ll
mJ5c2qLFj0XCVSIWwnM7oQscolVk5VYKbtXIG5ZtBDPGCwuSuG4OPM4U1s/5hAwX
1DweYZvavjOxEOimvNS2FkVRUXII50r07SbrgAqoxIgTA7iNQ9IJ6aiqC9mbf+YD
PZQbpFx8uGZUZDKHhkF9C6PROaYDgAqG6rPE01kWnWotTd8gjoVwGAGy3n0nn+Ph
NV5wf4cIJw==
=Hpzo
-----END PGP SIGNATURE-----

From bradsoto at protonmail.com  Tue Mar 23 22:21:21 2021
From: bradsoto at protonmail.com (Bradley Saulteaux)
Date: Tue, 23 Mar 2021 22:21:21 +0000
Subject: Wireguard Windows ARM64 Build 21327
In-Reply-To: <CAHmME9quO_Do25BaGOHX3Vdh3PPYRUeQR+U490HMYUpwemJKow@mail.gmail.com>
References: <nrcRMSny-jv34qB41pOjVZQJVY7-l1J7yFQ_bO740PasFTOqt9uNp8H8EctftDLEcNgOrxmydh8KJ3ZuTlS3FjmE2abkWJAXhmQTYhtnQlk=@protonmail.com>
 <CAHmME9q5HJ0QJMzqGBPjr-c4YSBcn3=JWjJB6BRAQtvzb02t6A@mail.gmail.com>
 <kvwelbya-mAZJ2wfpt2vqF1O0GE7BwijqjtQjshHnNMooW7y_J8W6BgMKM65sGgZEWZQx7Zr4uejYiDkfL07ckiwZKqt2DR7BNrnJtXUsHs=@protonmail.com>
 <CAHmME9qvexiP9ZFLMJfFEQEnaYHFZkPWmBUBwzdTs7Zov1poCA@mail.gmail.com>
 <CAHmME9qvh8PBGX-0mrnHDhxMF_+Do0JzjUf0L+hJkeiNfViqCw@mail.gmail.com>
 <LPfKC3Tqkdr8gYTfUyIox24RcE7O3rmYx4FbE-Js2TAQDlLFY-nEaj2PBum1YoZjv6oHyhPGQRDVOL0wNE2wD7BildydzjZ2d0qNVA8WhAs=@protonmail.com>
 <CAHmME9quO_Do25BaGOHX3Vdh3PPYRUeQR+U490HMYUpwemJKow@mail.gmail.com>
Message-ID: <OY4nN3X4ls8lWZ5VdHVz17N_03f7DWBP9hYHDyljz-HA0jzv7XrdW0VS6pHcWPYxWJYc0f2_ii8XBXO8WLXzEBNBf2xF1DoXZxHcrfYhCBg=@protonmail.com>

Brilliant! It works better than ever. The world needs more people like you sir, you do fantastic work. Thank you so much.


??????? Original Message ???????
On Monday, March 22, 2021 8:32 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:

> Hi again Bradley,
>
> https://github.com/golang/go/commit/78afca22c9485dbd44da3b909866bbb9c1eaf440
> was committed, and so WireGuard for Windows v0.3.9 was released. You
> said that you downgraded to some earlier arm32 version, so I imagine
> you've just been ignoring the update notification. Try updating now,
> and see if things go well.
>
> Jason



From karol at babioch.de  Thu Mar 25 22:35:06 2021
From: karol at babioch.de (Karol Babioch)
Date: Thu, 25 Mar 2021 23:35:06 +0100
Subject: Best strategy for multiple point-to-point tunnels
Message-ID: <93213ae2-3ad1-7f8a-1e21-57f672738e18@babioch.de>

Hi all,

first of all: Let me thank you for Wireguard, and all of the
discussion(s) and support here on this mailing list. It's super helpful
and getting started is actually quite easy!

I'm currently wondering what the best (TM) strategy for setting up
multiple point-to-point tunnels is. I'm actually not referring to "how
to manage this" (i.e. configuration management, etc.), but about whether
there is any recommendation on having multiple Wireguard instances (with
dedicated interfaces) vs. setting up a single Wireguard instances (with
multiple peers).

The reason I'm asking is that I'm coming from "OpenVPN world" and for
some reasons I'm actually used to setting up dedicated instances for
each tunnel. Essentially I have multiple OpenVPN instances running on
different ports - independent of each other.

Obviously this is no good for a typical "many clients, one server"
setup, but it has quite a few advantages for simple point-to-point tunnels:

a.) Better performance, since every instance has it's own process.
OpenVPN is notoriously CPU-bound and multi-threading has always been an
bottleneck.

b.) Easier to manage and understand firewall rules, as they can be based
on interface names (rather than IP addresses within a bigger subnet, etc.).

c.) Easier to manage TLS certificates. I'm used to generate "One-time
CAs" [2], i.e. there are only two certificates signed by a single CA. No
revocations and other complexities. This can be automated quite easily
and in case something is wrong, I can easily replace the certificate(s)
for this one tunnel without any effect on all of the other peers.

d.) Maybe the most important: Individual control for all settings (UDP
vs. TCP, MTU, cryptographic primitives, etc.). Sometimes it's hard to
find good, secure and modern settings for all clients, since not all of
them can be upgraded at once. For instance, some clients already support
TLS 1.3, while others do not, etc. OpenVPN allows for quite some
flexibility in that regard (e.g. peer-specific settings), but it was
always easier to have a configuration for every peer, rather than trying
to find the common denotator and/or deal with "client configuration
snippets", etc.

Now, looking at Wireguard, I'm wondering whether those thoughts are
still valid. I guess a.) and c.) are no longer valid concerns.

However b.) still is. For me it's still easier to write, understand and
manage firewall rules that are based on an interface name (i.e.
`wg-peername` vs. some seemingly "random" source IP from `wg0`).

The biggest concern on my end, though, currently is the "backwards
compability". So far Wireguard is the new kid in town and everything
works fine and is compability with each other, i.e. there are no
imcompatible versions / implementations, etc. That's great, of course.
Obviously, this is not a coincidence, but a design choice of the protocol.

However, the original whitepaper [1] also states:

> Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If
> holes are found in the underlying primitives, all endpoints will be required to update. As shown by the continuing
> torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.

While I can understand (and agree with) this reasoning, I'm wondering
what this will mean in the future, when there will be either new
versions / features and/or some security vulnerability that will require
a breaking change on the protocol level.

What will happen to my tunnels, when I update the "server". Will only
compatible clients be able to connect? Will there be some switch to
still allow connections from some old peer(s). Will it make a difference
whether I have only one interface or multiple interfaces?

I'm basically trying to prevent a situation, where I update the server,
and some/most of my peers will no longer be able to connect, because of
some breaking change. Upgrading everything at once will always be a
challenge: Sometimes you don't have access and/or are not control over
some systems, sometimes there might be other restrictions and/or simply
no update available for some (older) appliance, etc.

I know that most of this is still hypothetical at the current time and
that no one has experience with such situation(s) yet. However, maybe
there are some recommendations on how to deal with this?

What are your thoughts about this? Are you taking any additional
measures to make sure to not be affected by a breaking change later on?
What is your recommendation on handling multiple peer-to-peer tunnels?
Should I go for multiple interfaces or for one interface with multiple
peers?

Thank you for your input, already appreciated in advance.

Best regards,
Karol Babioch

[1]: https://www.wireguard.com/papers/wireguard.pdf
[2]: https://github.com/kbabioch/otca

From matthew.poletiek at gmail.com  Fri Mar 26 05:43:38 2021
From: matthew.poletiek at gmail.com (Matthew Poletiek)
Date: Fri, 26 Mar 2021 00:43:38 -0500
Subject: wireguard-android building the Tunnel
Message-ID: <CAJhSV8sPbHOWXjmCchMr=q3_bQatDMuxzcn2i=PVuyyQChnfhQ@mail.gmail.com>

Hello,

I'm messing around in android-studio and am trying to figure out how
to create the Tunnel for Backend.setState().

Trying to find documentation has been rough and I'm getting lost in the repo.

If anyone has any tips I'd greatly appreciate it.

Where does 'Tunnel' come from?

Thanks,
-------------------------------------------
Matthew Poletiek
303.810.9082
matthew.poletiek at gmail.com
www.matthewpoletiek.com

From adam.irr at outlook.com  Sat Mar 27 20:58:25 2021
From: adam.irr at outlook.com (Adam Irr)
Date: Sat, 27 Mar 2021 13:58:25 -0700
Subject: [PATCH] wg-quick: Android: Add up/down hook support
Message-ID: <DM6PR13MB24579CD788EF28E019933C0A92609@DM6PR13MB2457.namprd13.prod.outlook.com>

Hello,

I have been using my Nvidia Shield with a self-built kernel module as a 
Wireguard server with the support of this patch to have access to my 
home network. There is a corresponding change needed in the Android 
app[1] to make this work. I am not super familiar with C so please take 
time to scrutinize this code - particularly the memory management. If 
its easier to provide feedback on a Github pull request, let me know and 
I can open one.

[1] https://github.com/WireGuard/wireguard-android/pull/23

Thank you,

Adam

-----

>From 77e9153510fbcacafe20b2813ca11464768f1fd0 Mon Sep 17 00:00:00 2001
From: Adam Irr <adam.irr at outlook.com>
Date: Sat, 27 Mar 2021 13:47:09 -0700
Subject: [PATCH] wg-quick: Android: Add up/down hook support

This change allows Pre/Post Up/Down commands to be run
for Android devices. This provides a mechanism for Android
devices to behave like a server and automatically set up
routing rules.

Signed-off-by: Adam Irr <adam.irr at outlook.com>
---
 ?src/wg-quick/android.c | 91 ++++++++++++++++++++++++++++++++++++++----
 ?1 file changed, 84 insertions(+), 7 deletions(-)

diff --git a/src/wg-quick/android.c b/src/wg-quick/android.c
index 941c7b8..7d3cd03 100644
--- a/src/wg-quick/android.c
+++ b/src/wg-quick/android.c
@@ -1097,6 +1097,9 @@ static void cmd_usage(const char *program)
 ???? ??? "? - DNS: an optional DNS server to use while the device is up.\n"
 ???? ??? "? - ExcludedApplications: optional blacklist of applications 
to exclude from the tunnel.\n\n"
 ???? ??? "? - IncludedApplications: optional whitelist of applications 
to include in the tunnel.\n\n"
+??? ??? "? - PreUp, PostUp, PreDown, PostDown: script snippets which 
will be executed\n"
+??? ??? "??? by a root shell at the corresponding phases of the link.\n"
+??? ??? "??? The string \\`%i' is expanded to INTERFACE."
 ???? ??? "? See wg-quick(8) for more info and examples.\n");
 ?}

@@ -1110,7 +1113,39 @@ static void cmd_up_cleanup(void)
 ???? free(cleanup_iface);
 ?}

-static void cmd_up(const char *iface, const char *config, unsigned int 
mtu, const char *addrs, const char *dnses, const char 
*excluded_applications, const char *included_applications)
+static void run_hooks(const char *cmds, const char *iface)
+{
+??? if (cmds == NULL)
+??? ??? return;
+??? size_t len = strlen(cmds), iface_len = strlen(iface), j = 0, 
iface_count = 0;
+??? if (len > (1<<16))
+??? ??? return;
+??? for (size_t i = 0; i < len - 1; ++i) {
+??? ??? if (cmds[i] == '%' && cmds[++i] == 'i') {
+??? ??? ??? iface_count++;
+??? ??? }
+??? }
+
+??? // Allocate enough space for the full command after replacing %i 
with the interface name
+??? _cleanup_free_ char *current_cmd = xmalloc(len + ((iface_len - 2) * 
iface_count) + 1);
+
+??? for (size_t i = 0; i < len; ++i) {
+??? ??? if (cmds[i] != '\n') {
+??? ??? ??? if (cmds[i] == '%' && cmds[++i] == 'i') {
+??? ??? ??? ??? strcpy(current_cmd + j, iface);
+??? ??? ??? ??? j += iface_len;
+??? ??? ??? } else {
+??? ??? ??? ??? current_cmd[j++] = cmds[i];
+??? ??? ??? }
+??? ??? } else if (j != 0) {
+??? ??? ??? current_cmd[j] = '\0';
+??? ??? ??? j = 0;
+??? ??? ??? cmd("%s", current_cmd);
+??? ??? }
+??? }
+}
+
+static void cmd_up(const char *iface, const char *config, unsigned int 
mtu, const char *addrs, const char *dnses, const char 
*excluded_applications, const char *included_applications, const char 
*pre_up_cmds, const char *post_up_cmds)
 ?{
 ???? DEFINE_CMD(c);
 ???? unsigned int netid = 0;
@@ -1127,7 +1162,9 @@ static void cmd_up(const char *iface, const char 
*config, unsigned int mtu, cons
 ???? add_if(iface);
 ???? set_config(iface, config);
 ???? listen_port = determine_listen_port(iface);
+??? run_hooks(pre_up_cmds, iface);
 ???? up_if(&netid, iface, listen_port);
+??? run_hooks(post_up_cmds, iface);
 ???? set_addr(iface, addrs);
 ???? set_dnses(netid, dnses);
 ???? set_routes(iface, netid);
@@ -1140,7 +1177,7 @@ static void cmd_up(const char *iface, const char 
*config, unsigned int mtu, cons
 ???? exit(EXIT_SUCCESS);
 ?}

-static void cmd_down(const char *iface)
+static void cmd_down(const char *iface, char *pre_down_cmds, char 
*post_down_cmds)
 ?{
 ???? DEFINE_CMD(c);
 ???? bool found = false;
@@ -1159,12 +1196,32 @@ static void cmd_down(const char *iface)
 ???? ??? exit(EMEDIUMTYPE);
 ???? }

+??? run_hooks(pre_down_cmds, iface);
 ???? del_if(iface);
+??? run_hooks(post_down_cmds, iface);
 ???? broadcast_change();
 ???? exit(EXIT_SUCCESS);
 ?}

-static void parse_options(char **iface, char **config, unsigned int 
*mtu, char **addrs, char **dnses, char **excluded_applications, char 
**included_applications, const char *arg)
+static void clean_hook_cmd(const char *line, const size_t len, char 
*output)
+{
+??? size_t j = 0;
+??? bool found_prefix = false;
+??? bool found_cmd_start = false;
+??? for (size_t i = 0; i < len; ++i) {
+??????? if (!found_cmd_start && isspace(line[i]))
+??????????? continue;
+??????? if (found_prefix && !isspace(line[i]))
+??????????? found_cmd_start = true;
+??????? if (line[i] == '=')
+??????????? found_prefix = true;
+
+??????? output[j++] = line[i];
+??? }
+??? output[j] = '\0';
+}
+
+static void parse_options(char **iface, char **config, unsigned int 
*mtu, char **addrs, char **dnses, char **excluded_applications, char 
**included_applications, char **pre_up_cmds, char **post_up_cmds, char 
**pre_down_cmds, char **post_down_cmds, const char *arg)
 ?{
 ???? _cleanup_fclose_ FILE *file = NULL;
 ???? _cleanup_free_ char *line = NULL;
@@ -1254,6 +1311,22 @@ static void parse_options(char **iface, char 
**config, unsigned int *mtu, char *
 ???? ??? ??? } else if (!strncasecmp(clean, "MTU=", 4) && j > 4) {
 ???? ??? ??? ??? *mtu = atoi(clean + 4);
 ???? ??? ??? ??? continue;
+??? ??? ??? } else if (!strncasecmp(clean, "PreUp=", 6) && j > 4) {
+??? ??? ??? ??? clean_hook_cmd(line, len, clean);
+??? ??? ??? ??? *pre_up_cmds = concat_and_free(*pre_up_cmds, "\n", 
clean + 6);
+??? ??? ??? ??? continue;
+??? ??? ??? } else if (!strncasecmp(clean, "PostUp=", 7) && j > 4) {
+??? ??? ??? ??? clean_hook_cmd(line, len, clean);
+??? ??? ??? ??? *post_up_cmds = concat_and_free(*post_up_cmds, "\n", 
clean + 7);
+??? ??? ??? ??? continue;
+??? ??? ??? } else if (!strncasecmp(clean, "PreDown=", 8) && j > 4) {
+??? ??? ??? ??? clean_hook_cmd(line, len, clean);
+??? ??? ??? ??? *pre_down_cmds = concat_and_free(*pre_down_cmds, "\n", 
clean + 8);
+??? ??? ??? ??? continue;
+??? ??? ??? } else if (!strncasecmp(clean, "PostDown=", 9) && j > 4) {
+??? ??? ??? ??? clean_hook_cmd(line, len, clean);
+??? ??? ??? ??? *post_down_cmds = concat_and_free(*post_down_cmds, 
"\n", clean + 9);
+??? ??? ??? ??? continue;
 ???? ??? ??? }
 ???? ??? }
 ???? ??? *config = concat_and_free(*config, "", line);
@@ -1278,17 +1351,21 @@ int main(int argc, char *argv[])
 ???? _cleanup_free_ char *excluded_applications = NULL;
 ???? _cleanup_free_ char *included_applications = NULL;
 ???? unsigned int mtu;
+??? _cleanup_free_ char *pre_up_cmds = NULL;
+??? _cleanup_free_ char *post_up_cmds = NULL;
+??? _cleanup_free_ char *pre_down_cmds = NULL;
+??? _cleanup_free_ char *post_down_cmds = NULL;

 ???? if (argc == 2 && (!strcmp(argv[1], "help") || !strcmp(argv[1], 
"--help") || !strcmp(argv[1], "-h")))
 ???? ??? cmd_usage(argv[0]);
 ???? else if (argc == 3 && !strcmp(argv[1], "up")) {
 ???? ??? auto_su(argc, argv);
-??? ??? parse_options(&iface, &config, &mtu, &addrs, &dnses, 
&excluded_applications, &included_applications, argv[2]);
-??? ??? cmd_up(iface, config, mtu, addrs, dnses, excluded_applications, 
included_applications);
+??? ??? parse_options(&iface, &config, &mtu, &addrs, &dnses, 
&excluded_applications, &included_applications, &pre_up_cmds, 
&post_up_cmds, &pre_down_cmds, &post_down_cmds, argv[2]);
+??? ??? cmd_up(iface, config, mtu, addrs, dnses, excluded_applications, 
included_applications, pre_up_cmds, post_up_cmds);
 ???? } else if (argc == 3 && !strcmp(argv[1], "down")) {
 ???? ??? auto_su(argc, argv);
-??? ??? parse_options(&iface, &config, &mtu, &addrs, &dnses, 
&excluded_applications, &included_applications, argv[2]);
-??? ??? cmd_down(iface);
+??? ??? parse_options(&iface, &config, &mtu, &addrs, &dnses, 
&excluded_applications, &included_applications, &pre_up_cmds, 
&post_up_cmds, &pre_down_cmds, &post_down_cmds, argv[2]);
+??? ??? cmd_down(iface, pre_down_cmds, post_down_cmds);
 ???? } else {
 ???? ??? cmd_usage(argv[0]);
 ???? ??? return 1;
-- 
2.25.1


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-wg-quick-Android-Add-up-down-hook-support.patch
Type: text/x-patch
Size: 7191 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210327/1fe2514e/attachment.bin>

From ch at ntrv.dk  Tue Mar 30 11:53:34 2021
From: ch at ntrv.dk (Chriztoffer Hansen)
Date: Tue, 30 Mar 2021 13:53:34 +0200
Subject: Best strategy for multiple point-to-point tunnels
In-Reply-To: <93213ae2-3ad1-7f8a-1e21-57f672738e18@babioch.de>
References: <93213ae2-3ad1-7f8a-1e21-57f672738e18@babioch.de>
Message-ID: <CA+cYV6tQA=PkSsJkAKQ199q8qv74s1y_En4gBYwZiu9bHuwu_A@mail.gmail.com>

On Thu, 25 Mar 2021 at 23:35, Karol Babioch <karol at babioch.de> wrote:
> What is your recommendation on handling multiple peer-to-peer tunnels?
> Should I go for multiple interfaces or for one interface with multiple
> peers?

If you plan to do L3 routing over the P2P tunnels (e.g.
OSPF/BGP/EIGRP/Babel/etc.). A dedicated wg interface per remote
endpoint is generally recommended.

-- 
Chriztoffer


From ch at ntrv.dk  Tue Mar 30 11:55:46 2021
From: ch at ntrv.dk (Chriztoffer Hansen)
Date: Tue, 30 Mar 2021 13:55:46 +0200
Subject: Best strategy for multiple point-to-point tunnels
In-Reply-To: <CA+cYV6tQA=PkSsJkAKQ199q8qv74s1y_En4gBYwZiu9bHuwu_A@mail.gmail.com>
References: <93213ae2-3ad1-7f8a-1e21-57f672738e18@babioch.de>
 <CA+cYV6tQA=PkSsJkAKQ199q8qv74s1y_En4gBYwZiu9bHuwu_A@mail.gmail.com>
Message-ID: <CA+cYV6ve9iPTb5QzdUQ39DEY+7Weq_+OvVLfHi0Jkrx-LMmc_g@mail.gmail.com>

On Tue, 30 Mar 2021 at 13:53, Chriztoffer Hansen wrote:
>
> On Thu, 25 Mar 2021 at 23:35, Karol Babioch wrote:
> > What is your recommendation on handling multiple peer-to-peer tunnels?
> > Should I go for multiple interfaces or for one interface with multiple
> > peers?
>
> If you plan to do L3 routing over the P2P tunnels (e.g.
> OSPF/BGP/EIGRP/Babel/etc.). A dedicated wg interface per remote
> endpoint is generally recommended.

If you are doing a road-warrior style set-up. One WG interface (e.g.
per subnet for road-warrior groups) at your aggregation point/server
will be enough.

-- 
Chriztoffer


From frank at harz.behrens.de  Wed Mar 31 19:05:41 2021
From: frank at harz.behrens.de (Frank Behrens)
Date: Wed, 31 Mar 2021 21:05:41 +0200
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <89952f1f-5296-7f87-9345-0f5c087ee3ae@harz.behrens.de>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
 <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
 <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
 <CAHmME9qaMcd0R1zvFy+ZyW4a1vmX1bE_Rxf4WFgau4UTdEi7hQ@mail.gmail.com>
 <CAHmME9r13tPji0Guw3_Q8k4grh046RkSccPLbEVAasKQ=BNkVw@mail.gmail.com>
 <89952f1f-5296-7f87-9345-0f5c087ee3ae@harz.behrens.de>
Message-ID: <a5cdf813-3cf6-b5e6-d497-78980c681958@harz.behrens.de>

Hello!

Am 23.03.2021 um 06:51 schrieb Frank Behrens:
> Am 22.03.2021 um 19:14 schrieb Jason A. Donenfeld:
>> Applied to git with some small modifications:
>>
>> https://git.zx2c4.com/wireguard-freebsd/commit/?id=0a5c6abdfaa1f4f09269a222c1720e2ff3b8aa02 
>>
> Thanky you! That looks very good.

I'm sorry, that I didn't test this in detail. Unfortunately it does not 
work, I made a patch in branch fb/fib2.

Kind regards,
 ??? Frank

-- 
Frank Behrens
Osterwieck, Germany


From Jason at zx2c4.com  Wed Mar 31 19:11:36 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 31 Mar 2021 13:11:36 -0600
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <a5cdf813-3cf6-b5e6-d497-78980c681958@harz.behrens.de>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
 <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
 <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
 <CAHmME9qaMcd0R1zvFy+ZyW4a1vmX1bE_Rxf4WFgau4UTdEi7hQ@mail.gmail.com>
 <CAHmME9r13tPji0Guw3_Q8k4grh046RkSccPLbEVAasKQ=BNkVw@mail.gmail.com>
 <89952f1f-5296-7f87-9345-0f5c087ee3ae@harz.behrens.de>
 <a5cdf813-3cf6-b5e6-d497-78980c681958@harz.behrens.de>
Message-ID: <CAHmME9rCzvFGv3=ZwurVMnax0RzKQr2mTCAgqT9EY8MEbJ24Ng@mail.gmail.com>

Hi Frank,

Thanks for the patch. Does the line `so4->so_fibnum = so6->so_fibnum =
sc->sc_socket.so_fibnum;` also need to be changed too in initiation,
or is that one fine?

Jason

From frank at harz.behrens.de  Wed Mar 31 19:16:09 2021
From: frank at harz.behrens.de (Frank Behrens)
Date: Wed, 31 Mar 2021 21:16:09 +0200
Subject: [PATCH] freebsd: Implement selection of FIB (routing table) for
 tunneled packets
In-Reply-To: <CAHmME9rCzvFGv3=ZwurVMnax0RzKQr2mTCAgqT9EY8MEbJ24Ng@mail.gmail.com>
References: <6aa0fd33-4c0d-557f-f7f5-5f5406b3a273@harz.behrens.de>
 <CAHmME9q6dO1X+Gt3hY4kQxsQ4DqeaJGxoT8qkaAe-0s_WCrVrA@mail.gmail.com>
 <ee43587f-8e17-add1-6b28-174639d126f8@harz.behrens.de>
 <CAHmME9qaMcd0R1zvFy+ZyW4a1vmX1bE_Rxf4WFgau4UTdEi7hQ@mail.gmail.com>
 <CAHmME9r13tPji0Guw3_Q8k4grh046RkSccPLbEVAasKQ=BNkVw@mail.gmail.com>
 <89952f1f-5296-7f87-9345-0f5c087ee3ae@harz.behrens.de>
 <a5cdf813-3cf6-b5e6-d497-78980c681958@harz.behrens.de>
 <CAHmME9rCzvFGv3=ZwurVMnax0RzKQr2mTCAgqT9EY8MEbJ24Ng@mail.gmail.com>
Message-ID: <b6bc4f92-07aa-a2ab-e7be-2775316a4def@harz.behrens.de>

Hello Jason!

Am 31.03.2021 um 21:11 schrieb Jason A. Donenfeld:
> Hi Frank,
>
> Thanks for the patch. Does the line `so4->so_fibnum = so6->so_fibnum =
> sc->sc_socket.so_fibnum;` also need to be changed too in initiation,
> or is that one fine?
Good catch! I'll check this in the next few days (and update the branch 
if necessary).

Frank

-- 
Frank Behrens
Osterwieck, Germany