From michael.adm at gmail.com  Thu Sep  1 05:40:07 2022
From: michael.adm at gmail.com (Michael Pro)
Date: Thu, 1 Sep 2022 08:40:07 +0300
Subject: FreeBSD current socket-src changed. Wireguard not compiling.
In-Reply-To: <CAPyFy2DWRu+9ctBiLRpzYdzRj7+tBB_fa1RQM7kwJTz7tTtLvA@mail.gmail.com>
References: <CAA+Mow79-=J1LmFWdFOEnVnV4QCKyWb13YsvzOrsxtWV=GgJ7A@mail.gmail.com>
 <YwzmY6Q/lJIDZyfz@zx2c4.com>
 <CAPyFy2DWRu+9ctBiLRpzYdzRj7+tBB_fa1RQM7kwJTz7tTtLvA@mail.gmail.com>
Message-ID: <CAA+Mow5Pq7MBUCxvnTUsdnBhwduVh-VywFLoyTNy4G65XcAyvQ@mail.gmail.com>

FreeBSD Current (14.0)
http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/14.0/
sources from iso or github - no matther
Changes to src are made by commit e7d02be19d40063783d6b8f1ff2bc4c7170fd434
Author Gleb Smirnoff <glebius at FreeBSD.org> Wed, 17 Aug 2022 21:50:32
+0300 (11:50 -0700)

??, 31 ???. 2022 ?. ? 21:18, Ed Maste <emaste at freebsd.org>:
>
> On Mon, 29 Aug 2022 at 12:18, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> > On Tue, Aug 23, 2022 at 12:26:21PM +0300, Michael Pro wrote:
> > > Tonight after updating kernel freebsd current I got coredump with
> > > wireguard enabled kernel module.
> > > ...
> > Thanks. Is there a __FreeBSD_version__ change that corresponds?
>
> It is not an exact match, but was bumped to 1400066 shortly after and
> should be a suitable value to check.

From post at steffenvogel.de  Fri Sep  2 15:16:34 2022
From: post at steffenvogel.de (Steffen Vogel)
Date: Fri, 02 Sep 2022 17:16:34 +0200
Subject: [PATCH] =?utf-8?q?wireguard-go/device=3A?= add new handshake handler
 and keylog writer
Message-ID: <4d-63121e80-3-6ef3e80@7869515>

(This path is also tracked as PR: https://github.com/WireGuard/wireguard-go/pull/56)

This change adds support for a new environment variable 'WG_KEYLOGFILE'
in resemblance to the 'SSLKEYLOGFILE' environment variable used by
curl, Chrome & Firefox to log ephemeral TLS encryption keys

When set, wireguard-go will log ephemeral keys generated during
each handshake to a file specified by the environment variable in the
WireGuard key log format.

The format used is the same as then one generated by the
extract-handshakes.sh script.

See also:
- https://git.zx2c4.com/wireguard-tools/tree/contrib/extract-handshakes
- https://wiki.wireshark.org/WireGuard#key-log-format
- https://everything.curl.dev/usingcurl/tls/sslkeylogfile

Signed-off-by: Steffen Vogel post at steffenvogel.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-device-add-new-handshake-handler-and-keylog-writer.patch
Type: application/octet-stream
Size: 6488 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220902/279ac410/attachment.obj>

From Jason at zx2c4.com  Sun Sep  4 17:07:32 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 4 Sep 2022 19:07:32 +0200
Subject: FreeBSD current socket-src changed. Wireguard not compiling.
In-Reply-To: <CAPyFy2DWRu+9ctBiLRpzYdzRj7+tBB_fa1RQM7kwJTz7tTtLvA@mail.gmail.com>
References: <CAA+Mow79-=J1LmFWdFOEnVnV4QCKyWb13YsvzOrsxtWV=GgJ7A@mail.gmail.com>
 <YwzmY6Q/lJIDZyfz@zx2c4.com>
 <CAPyFy2DWRu+9ctBiLRpzYdzRj7+tBB_fa1RQM7kwJTz7tTtLvA@mail.gmail.com>
Message-ID: <CAHmME9oqxSuV2b4ZtHqenscfJfWi72mcQgebDi2pgTT7n_62Ng@mail.gmail.com>

Hi Ed,

On Wed, Aug 31, 2022 at 8:18 PM Ed Maste <emaste at freebsd.org> wrote:
>
> On Mon, 29 Aug 2022 at 12:18, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> > On Tue, Aug 23, 2022 at 12:26:21PM +0300, Michael Pro wrote:
> > > Tonight after updating kernel freebsd current I got coredump with
> > > wireguard enabled kernel module.
> > > ...
> > Thanks. Is there a __FreeBSD_version__ change that corresponds?
>
> It is not an exact match, but was bumped to 1400066 shortly after and
> should be a suitable value to check.

Thanks.

Michael - could you give this a try?
https://git.zx2c4.com/wireguard-freebsd/commit/?id=89b7292797c17449e24f5b8b08cb2412a51d2484

Jason

From Jason at zx2c4.com  Sun Sep  4 17:20:43 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 4 Sep 2022 19:20:43 +0200
Subject: FreeBSD current socket-src changed. Wireguard not compiling.
In-Reply-To: <CAHmME9oqxSuV2b4ZtHqenscfJfWi72mcQgebDi2pgTT7n_62Ng@mail.gmail.com>
References: <CAA+Mow79-=J1LmFWdFOEnVnV4QCKyWb13YsvzOrsxtWV=GgJ7A@mail.gmail.com>
 <YwzmY6Q/lJIDZyfz@zx2c4.com>
 <CAPyFy2DWRu+9ctBiLRpzYdzRj7+tBB_fa1RQM7kwJTz7tTtLvA@mail.gmail.com>
 <CAHmME9oqxSuV2b4ZtHqenscfJfWi72mcQgebDi2pgTT7n_62Ng@mail.gmail.com>
Message-ID: <CAHmME9rN=kqPz0KgWUyhQ=4q=HLwkUL8cSXTnJ5ySmdgs4N8Xg@mail.gmail.com>

On Sun, Sep 4, 2022 at 7:07 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Ed,
>
> On Wed, Aug 31, 2022 at 8:18 PM Ed Maste <emaste at freebsd.org> wrote:
> >
> > On Mon, 29 Aug 2022 at 12:18, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> > > On Tue, Aug 23, 2022 at 12:26:21PM +0300, Michael Pro wrote:
> > > > Tonight after updating kernel freebsd current I got coredump with
> > > > wireguard enabled kernel module.
> > > > ...
> > > Thanks. Is there a __FreeBSD_version__ change that corresponds?
> >
> > It is not an exact match, but was bumped to 1400066 shortly after and
> > should be a suitable value to check.
>
> Thanks.
>
> Michael - could you give this a try?
> https://git.zx2c4.com/wireguard-freebsd/commit/?id=89b7292797c17449e24f5b8b08cb2412a51d2484

Err, that would be the wrong code copy&paste. This, I meant:
https://git.zx2c4.com/wireguard-freebsd/commit/?id=20584d1c329ed2a71893375fa11ca4c56ed9f642

From houmie at gmail.com  Tue Sep 13 12:41:59 2022
From: houmie at gmail.com (Houman)
Date: Tue, 13 Sep 2022 13:41:59 +0100
Subject: Wireguard iOS crashes after upgrading to XCode 14
Message-ID: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>

My existing Wireguard iOS implementation stopped working after
upgrading to Xcode 14 today.
When trying to connect to servers that support only IPv4, then it's
fine. But if the server supports both IPv6 and IPv4 then the tunnel
crashes:

This IPv6 extension in
wireguard-apple/Sources/WireGuardKit/IPAddress+AddrInfo.swift crashes
with a Fatal Error at addrInfo.ai_addr.withMemoryRebound()

The whole extension below:

extension IPv6Address {
    init?(addrInfo: addrinfo) {
        guard addrInfo.ai_family == AF_INET6 else { return nil }

        let addressData = addrInfo.ai_addr.withMemoryRebound(to:
sockaddr_in6.self, capacity: MemoryLayout<sockaddr_in6>.size) { ptr ->
Data in
            return Data(bytes: &ptr.pointee.sin6_addr, count:
MemoryLayout<in6_addr>.size)
        }
        self.init(addressData)
    }
}

Has anyone else experienced this problem?

Thanks,

From syzbot+a448cda4dba2dac50de5 at syzkaller.appspotmail.com  Tue Sep 13 19:51:42 2022
From: syzbot+a448cda4dba2dac50de5 at syzkaller.appspotmail.com (syzbot)
Date: Tue, 13 Sep 2022 12:51:42 -0700
Subject: [syzbot] linux-next test error: WARNING in set_peer
Message-ID: <00000000000060a74405e8945759@google.com>

Hello,

syzbot found the following issue on:

HEAD commit:    0caac1da9949 Add linux-next specific files for 20220913
git tree:       linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=172d78d8880000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2fd6142ea1cf631c
dashboard link: https://syzkaller.appspot.com/bug?extid=a448cda4dba2dac50de5
compiler:       gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/4916ab25f774/disk-0caac1da.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/16dace3b273b/vmlinux-0caac1da.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+a448cda4dba2dac50de5 at syzkaller.appspotmail.com

netdevsim netdevsim0 netdevsim1: renamed from eth1
netdevsim netdevsim0 netdevsim2: renamed from eth2
netdevsim netdevsim0 netdevsim3: renamed from eth3
------------[ cut here ]------------
memcpy: detected field-spanning write (size 28) of single field "&endpoint.addr" at drivers/net/wireguard/netlink.c:446 (size 16)
WARNING: CPU: 0 PID: 3616 at drivers/net/wireguard/netlink.c:446 set_peer+0x991/0x10c0 drivers/net/wireguard/netlink.c:446
Modules linked in:
CPU: 0 PID: 3616 Comm: syz-executor.0 Not tainted 6.0.0-rc5-next-20220913-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022
RIP: 0010:set_peer+0x991/0x10c0 drivers/net/wireguard/netlink.c:446
Code: 00 e8 63 30 b3 fc b9 10 00 00 00 48 c7 c2 00 4c 72 8a be 1c 00 00 00 48 c7 c7 60 4c 72 8a c6 05 d0 e7 02 09 01 e8 f1 d7 74 04 <0f> 0b e9 03 04 00 00 e8 33 30 b3 fc 89 ee 44 89 ef e8 79 2c b3 fc
RSP: 0018:ffffc90003d4f540 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffffc90003d4f6d8 RCX: 0000000000000000
RDX: ffff888072ed57c0 RSI: ffffffff81611eb8 RDI: fffff520007a9e9a
RBP: ffffc90003d4f5e8 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000080000000 R11: 7720676e696e6e6d R12: 000000000000001c
R13: 0000000000000000 R14: ffff888072f1d104 R15: ffff888024cb0960
FS:  000055555616b400(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa5644d32c0 CR3: 000000006e43c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 wg_set_device+0x8d7/0x11b0 drivers/net/wireguard/netlink.c:589
 genl_family_rcv_msg_doit+0x228/0x320 net/netlink/genetlink.c:731
 genl_family_rcv_msg net/netlink/genetlink.c:778 [inline]
 genl_rcv_msg+0x3b7/0x630 net/netlink/genetlink.c:795
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2540
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:806
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:734
 __sys_sendto+0x236/0x340 net/socket.c:2117
 __do_sys_sendto net/socket.c:2129 [inline]
 __se_sys_sendto net/socket.c:2125 [inline]
 __x64_sys_sendto+0xdd/0x1b0 net/socket.c:2125
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fa56343c18c
Code: fa fa ff ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b 7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 20 fb ff ff 48 8b
RSP: 002b:00007ffe4bc97580 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007fa5644d4320 RCX: 00007fa56343c18c
RDX: 0000000000000170 RSI: 00007fa5644d4370 RDI: 0000000000000005
RBP: 0000000000000000 R08: 00007ffe4bc975d4 R09: 000000000000000c
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
R13: 00007fa5644d4370 R14: 0000000000000005 R15: 0000000000000000
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller at googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

From keescook at chromium.org  Wed Sep 14 00:55:39 2022
From: keescook at chromium.org (Kees Cook)
Date: Tue, 13 Sep 2022 17:55:39 -0700
Subject: [syzbot] linux-next test error: WARNING in set_peer
In-Reply-To: <00000000000060a74405e8945759@google.com>
References: <00000000000060a74405e8945759@google.com>
Message-ID: <202209131753.D1BDA803@keescook>

On Tue, Sep 13, 2022 at 12:51:42PM -0700, syzbot wrote:
> memcpy: detected field-spanning write (size 28) of single field "&endpoint.addr" at drivers/net/wireguard/netlink.c:446 (size 16)

This is one way to fix it:

diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index 0c0644e762e5..dbbeba216530 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -434,16 +434,16 @@ static int set_peer(struct wg_device *wg, struct nlattr **attrs)
 	}
 
 	if (attrs[WGPEER_A_ENDPOINT]) {
-		struct sockaddr *addr = nla_data(attrs[WGPEER_A_ENDPOINT]);
+		struct endpoint *raw = nla_data(attrs[WGPEER_A_ENDPOINT]);
 		size_t len = nla_len(attrs[WGPEER_A_ENDPOINT]);
 
 		if ((len == sizeof(struct sockaddr_in) &&
-		     addr->sa_family == AF_INET) ||
+		     raw->addr.sa_family == AF_INET) ||
 		    (len == sizeof(struct sockaddr_in6) &&
-		     addr->sa_family == AF_INET6)) {
+		     raw->addr.sa_family == AF_INET6)) {
 			struct endpoint endpoint = { { { 0 } } };
 
-			memcpy(&endpoint.addr, addr, len);
+			memcpy(&endpoint.addrs, &raw->addrs, len);
 			wg_socket_set_peer_endpoint(peer, &endpoint);
 		}
 	}
diff --git a/drivers/net/wireguard/peer.h b/drivers/net/wireguard/peer.h
index 76e4d3128ad4..4fbe7940828b 100644
--- a/drivers/net/wireguard/peer.h
+++ b/drivers/net/wireguard/peer.h
@@ -19,11 +19,13 @@
 struct wg_device;
 
 struct endpoint {
-	union {
-		struct sockaddr addr;
-		struct sockaddr_in addr4;
-		struct sockaddr_in6 addr6;
-	};
+	struct_group(addrs,
+		union {
+			struct sockaddr addr;
+			struct sockaddr_in addr4;
+			struct sockaddr_in6 addr6;
+		};
+	);
 	union {
 		struct {
 			struct in_addr src4;


diffoscope shows the bounds check gets updated to the full union size:
? -     cmp    $0x11,%edx
? +     cmp    $0x1d,%edx

and the field name changes in the warning:
$ strings clang/drivers/net/wireguard/netlink.o.after | grep ^field
field "&endpoint.addrs" at drivers/net/wireguard/netlink.c:446


-- 
Kees Cook

From Jason at zx2c4.com  Wed Sep 14 17:48:52 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 14 Sep 2022 18:48:52 +0100
Subject: [syzbot] linux-next test error: WARNING in set_peer
In-Reply-To: <202209131753.D1BDA803@keescook>
References: <00000000000060a74405e8945759@google.com>
 <202209131753.D1BDA803@keescook>
Message-ID: <YyIUBKYWJBilWK3A@zx2c4.com>

I think I'll open code it like below. I'll include this in my next push
to net.

>From 19fb26af00a8266df65b706dc02727c6a608b1b6 Mon Sep 17 00:00:00 2001
From: "Jason A. Donenfeld" <Jason at zx2c4.com>
Date: Wed, 14 Sep 2022 18:42:00 +0100
Subject: [PATCH] wireguard: netlink: avoid variable-sized memcpy on sockaddr

Doing a variable-sized memcpy is slower, and the compiler isn't smart
enough to turn this into a constant-size assignment.

Further, Kees' latest fortified memcpy will actually bark, because the
destination pointer is type sockaddr, not explicitly sockaddr_in or
sockaddr_in6, so it thinks there's an overflow:

    memcpy: detected field-spanning write (size 28) of single field
    "&endpoint.addr" at drivers/net/wireguard/netlink.c:446 (size 16)

Fix this by just assigning by using explicit casts for each checked
case.

Cc: Kees Cook <keescook at chromium.org>
Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
---
 drivers/net/wireguard/netlink.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c
index d0f3b6d7f408..5c804bcabfe6 100644
--- a/drivers/net/wireguard/netlink.c
+++ b/drivers/net/wireguard/netlink.c
@@ -436,14 +436,13 @@ static int set_peer(struct wg_device *wg, struct nlattr **attrs)
 	if (attrs[WGPEER_A_ENDPOINT]) {
 		struct sockaddr *addr = nla_data(attrs[WGPEER_A_ENDPOINT]);
 		size_t len = nla_len(attrs[WGPEER_A_ENDPOINT]);
+		struct endpoint endpoint = { { { 0 } } };

-		if ((len == sizeof(struct sockaddr_in) &&
-		     addr->sa_family == AF_INET) ||
-		    (len == sizeof(struct sockaddr_in6) &&
-		     addr->sa_family == AF_INET6)) {
-			struct endpoint endpoint = { { { 0 } } };
-
-			memcpy(&endpoint.addr, addr, len);
+		if (len == sizeof(struct sockaddr_in) && addr->sa_family == AF_INET) {
+			endpoint.addr4 = *(struct sockaddr_in *)addr;
+			wg_socket_set_peer_endpoint(peer, &endpoint);
+		} else if (len == sizeof(struct sockaddr_in6) && addr->sa_family == AF_INET6) {
+			endpoint.addr6 = *(struct sockaddr_in6 *)addr;
 			wg_socket_set_peer_endpoint(peer, &endpoint);
 		}
 	}
--
2.37.3

From s.devanath at gmail.com  Mon Sep 19 17:47:29 2022
From: s.devanath at gmail.com (Devanath S)
Date: Mon, 19 Sep 2022 10:47:29 -0700
Subject: wireguard-go on MACos
Message-ID: <CADjMg7XtPWoozpBikNGP=EDCYvH=dr3Uo60emPXGvUv0MbJvVQ@mail.gmail.com>

Hi All,

We are using wireguard-go on MACOS/LINUX and a dns-proxy is listening
on wireguard device. dns-proxy is receiving dns requests from the
desktop (destined to wireguarddeviceip:53) on linuxos. But the same
does not work on MACos.

I have tried to create tun/ap using go-library (water) and was able to
receive the requests, but the same fails when using a wireguard device
created using wireguard-go. Also ping to wireguard device ip from the
desktop fails miserably.

I am kind of blocked, Appreciate any help regarding this.

Regards,
Dev

From ms at kilabit.info  Mon Sep 19 18:29:39 2022
From: ms at kilabit.info (Shulhan)
Date: Tue, 20 Sep 2022 01:29:39 +0700
Subject: wireguard-go on MACos
In-Reply-To: <CADjMg7XtPWoozpBikNGP=EDCYvH=dr3Uo60emPXGvUv0MbJvVQ@mail.gmail.com>
References: <CADjMg7XtPWoozpBikNGP=EDCYvH=dr3Uo60emPXGvUv0MbJvVQ@mail.gmail.com>
Message-ID: <20220920012939.78a8be42@inspiro.localdomain>

Hi Dev,

On Mon, 19 Sep 2022 10:47:29 -0700
Devanath S <s.devanath at gmail.com> wrote:

> Hi All,
> 
> We are using wireguard-go on MACOS/LINUX and a dns-proxy is listening
> on wireguard device. dns-proxy is receiving dns requests from the
> desktop (destined to wireguarddeviceip:53) on linuxos. But the same
> does not work on MACos.
> 
> I have tried to create tun/ap using go-library (water) and was able to
> receive the requests, but the same fails when using a wireguard device
> created using wireguard-go. Also ping to wireguard device ip from the
> desktop fails miserably.
> 

I assume you want to make all peers request to the same DNS server, yes?

In that case, instead of installing dns-proxy on each user, setup a
central DNS server and let the WireGuard handle the rest.

For example, in my experience, I setup rescached [1] (or any DNS
caches/forwarder) on the "server" peer at 10.8.0.1 and set the DNS
option on each "client" peer to that address

  [Interface]
  ...
  DNS = 10.8.0.1

With this mode, client does not need to install or setup anything except
the WireGuard application.

[1] https://kilabit.info/project/rescached

-- 
{ "git":"git.sr.ht/~shulhan", "site":"kilabit.info" }
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220920/944f4180/attachment.sig>

From s.devanath at gmail.com  Mon Sep 19 18:55:42 2022
From: s.devanath at gmail.com (Devanath S)
Date: Mon, 19 Sep 2022 11:55:42 -0700
Subject: wireguard-go on MACos
In-Reply-To: <CADjMg7XtPWoozpBikNGP=EDCYvH=dr3Uo60emPXGvUv0MbJvVQ@mail.gmail.com>
References: <CADjMg7XtPWoozpBikNGP=EDCYvH=dr3Uo60emPXGvUv0MbJvVQ@mail.gmail.com>
Message-ID: <CADjMg7VnQ4Zq=fA7nNJNH+b_5DcZdJpZ1-FfKC1caFB49rkBFw@mail.gmail.com>

Hi Shulhan,

Yes, we already do that. In split tunnel mode, we cannot make all
traffic to reach the wireguard server (only a subset of the traffic is
routed through the tunnel).

SO the feature is specific domain name requests will be directed to
dns proxy running on wireguard device => proxy forwards to wireguard
service (where the dns server resides) through the tunnel. For the
rest of the domain names, they are resolved using the primary DNS
server on the desktop.
This works as expected when we run the DNS proxy on localhost. But
want it to listen on wireguard device ipaddress instead. This fails on
MACos. Hope it makes sense. Thanx in advance.


Regards,
Dev
------

> Hi Dev,

> On Mon, 19 Sep 2022 10:47:29 -0700
> Devanath S <s.devan... at gmail.com> wrote:

> Hi All,
>
> We are using wireguard-go on MACOS/LINUX and a dns-proxy is listening
> on wireguard device. dns-proxy is receiving dns requests from the
> desktop (destined to wireguarddeviceip:53) on linuxos. But the same
> does not work on MACos.
>
> I have tried to create tun/ap using go-library (water) and was able to
> receive the requests, but the same fails when using a wireguard device
> created using wireguard-go. Also ping to wireguard device ip from the
> desktop fails miserably.
>

I assume you want to make all peers request to the same DNS server, yes?

In that case, instead of installing dns-proxy on each user, setup a
central DNS server and let the WireGuard handle the rest.

For example, in my experience, I setup rescached [1] (or any DNS
caches/forwarder) on the "server" peer at 10.8.0.1 and set the DNS
option on each "client" peer to that address

  [Interface]
  ...
  DNS = 10.8.0.1

With this mode, client does not need to install or setup anything except
the WireGuard application.

On Mon, Sep 19, 2022 at 10:47 AM Devanath S <s.devanath at gmail.com> wrote:
>
> Hi All,
>
> We are using wireguard-go on MACOS/LINUX and a dns-proxy is listening
> on wireguard device. dns-proxy is receiving dns requests from the
> desktop (destined to wireguarddeviceip:53) on linuxos. But the same
> does not work on MACos.
>
> I have tried to create tun/ap using go-library (water) and was able to
> receive the requests, but the same fails when using a wireguard device
> created using wireguard-go. Also ping to wireguard device ip from the
> desktop fails miserably.
>
> I am kind of blocked, Appreciate any help regarding this.
>
> Regards,
> Dev

From wireguard-mail at chil.at  Tue Sep 20 08:11:29 2022
From: wireguard-mail at chil.at (Christoph Loesch)
Date: Tue, 20 Sep 2022 10:11:29 +0200
Subject: WireGuard App on Android allows only one connection simultaneously
Message-ID: <62cc526e-7b02-3529-d575-87434af15bd3@chil.at>

Hi,

on Linux multiple connections at the same time are possible, on Windows also. I don't have a Mac so I can't test there.

When having two tunnels configured in the Android App, while one is connected if I connect to the second one, the first one disconnects.

Is there any reason as why the Android App only allows one connection at the same time?

Thank you and kind regards,
Christoph


From simon.karberg at agillic.com  Wed Sep 21 07:28:49 2022
From: simon.karberg at agillic.com (Simon Karberg)
Date: Wed, 21 Sep 2022 09:28:49 +0200
Subject: MacOS app update needed
Message-ID: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>

Hi,

I've been testing the Domain Search functionality on all 3 OS'
(Windows, Mac & Linux) and the setting:

DNS=<dns server>, <search domains>
Is only being applied on Windows & Linux.

Further testing on MacOS I've found that the homebrew installation works.
wiregurd-go is version 0.0.20220316 and wireguard-tools is version 1.0.20210914

The App Store app is version:
App: 1.0.15 (26)
Go backend: 2ef39d47

The app in the App Store hasn't been updated in 11 months, maybe it's
time to get it on the newest backend?

From houmie at gmail.com  Wed Sep 21 07:52:09 2022
From: houmie at gmail.com (Houman)
Date: Wed, 21 Sep 2022 08:52:09 +0100
Subject: MacOS app update needed
In-Reply-To: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
Message-ID: <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>

Hi Simon,

Not only that, even the repo
https://github.com/WireGuard/wireguard-apple hasn't been updated since
27 Sep 2021.
There are a number of useful contributions in the form of pull
requests waiting there to be approved for over 8 months.

The project feels abandoned, which is such a shame.

Regards,
Houman


On Wed, 21 Sept 2022 at 08:33, Simon Karberg <simon.karberg at agillic.com> wrote:
>
> Hi,
>
> I've been testing the Domain Search functionality on all 3 OS'
> (Windows, Mac & Linux) and the setting:
>
> DNS=<dns server>, <search domains>
> Is only being applied on Windows & Linux.
>
> Further testing on MacOS I've found that the homebrew installation works.
> wiregurd-go is version 0.0.20220316 and wireguard-tools is version 1.0.20210914
>
> The App Store app is version:
> App: 1.0.15 (26)
> Go backend: 2ef39d47
>
> The app in the App Store hasn't been updated in 11 months, maybe it's
> time to get it on the newest backend?

From bandry at ut1.org  Wed Sep 21 08:20:07 2022
From: bandry at ut1.org (Bruno)
Date: Wed, 21 Sep 2022 10:20:07 +0200
Subject: MacOS app update needed
In-Reply-To: <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
Message-ID: <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>

Hi,

Windows Client project don't feel alive either. Last commit has 6 months 
and last release is 9 month old.

Same, here https://git.zx2c4.com/wireguard-windows/log/ and here 
https://github.com/WireGuard/wireguard-windows

Version 0.5.3 works well, but I suppose it can be even better!

Any plans for some update?

Regards

Bruno

Le 21/09/2022 ? 09:52, Houman a ?crit?:
> Hi Simon,
>
> Not only that, even the repo
> https://github.com/WireGuard/wireguard-apple hasn't been updated since
> 27 Sep 2021.
> There are a number of useful contributions in the form of pull
> requests waiting there to be approved for over 8 months.
>
> The project feels abandoned, which is such a shame.
>
> Regards,
> Houman

From simon at rozman.si  Wed Sep 21 08:29:17 2022
From: simon at rozman.si (Simon Rozman)
Date: Wed, 21 Sep 2022 08:29:17 +0000
Subject: WireGuard App on Android allows only one connection simultaneously
In-Reply-To: <62cc526e-7b02-3529-d575-87434af15bd3@chil.at>
References: <62cc526e-7b02-3529-d575-87434af15bd3@chil.at>
Message-ID: <30014af580cd42edba0121c0d6b99add@rozman.si>

Hi,

> on Linux multiple connections at the same time are possible, on Windows
> also. I don't have a Mac so I can't test there.
> 
> When having two tunnels configured in the Android App, while one is
> connected if I connect to the second one, the first one disconnects.
> 
> Is there any reason as why the Android App only allows one connection at
> the same time?

Unfortunately, this is a limitation of Android OS supporting only 1 (one) VPN connection at a time.

Regards,
Simon

From endre.szabo at wg-ml-rkaofgr.redir.email  Wed Sep 21 08:56:21 2022
From: endre.szabo at wg-ml-rkaofgr.redir.email (Endre Szabo)
Date: Wed, 21 Sep 2022 08:56:21 +0000
Subject: WireGuard App on Android allows only one connection simultaneously
In-Reply-To: <30014af580cd42edba0121c0d6b99add@rozman.si>
References: <62cc526e-7b02-3529-d575-87434af15bd3@chil.at>
 <30014af580cd42edba0121c0d6b99add@rozman.si>
Message-ID: <393311a3ac9b1ed9cb909ba6eb1b364b@wg-ml-rkaofgr.redir.email>

Hi,

On Wed, Sep 21, 2022 at 08:29:17+0000, Simon Rozman wrote:
> Unfortunately, this is a limitation of Android OS supporting only 1 (one) VPN connection at a time.
Just a theoretical thought experiment (I don't know Android arch well, I might be wrong at any of these points):
 
- AFAIK, having a VPN (VPN app) on an Android involves creating a tun device for that app
- kernel RPDB mumbo-jumbo (Android has set that up) will route (all or app-specific (based on processid?) selected) traffic to that VPN app
- the VPN app will be left with 'the default routing table' free to establish unlimited outbound unencrypted connections
- WG on android is implemented in userspace, in the WG app (using go implementation?)
- Since this app has unlimited/untunneled access via 'the default routing table' it is free to establish more than 1 WG sessions (of course, in-app cryptokey routing and all the usual limitations still apply)
- Current WG app (and especially its widget) will not allow only one VPN session at a time.
 
Would it be possible to lift this limitation? Or is this limitation of another nature?

--Endre

From and at mullvad.net  Thu Sep 22 08:31:52 2022
From: and at mullvad.net (Andrej Mihajlov)
Date: Thu, 22 Sep 2022 10:31:52 +0200
Subject: Wireguard iOS crashes after upgrading to XCode 14
In-Reply-To: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
References: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
Message-ID: <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>

Hi,

I think we have a bug. If I am right, basically in both IPv4 and IPv6 extensions, withMemoryRebound takes capacity which is actually a number of instances of a given type (sockaddr_ variant) and not the byte size of a struct. 

Could you please patch your WireGuardKit with the following commit and see if it helps? 

https://git.zx2c4.com/wireguard-apple/commit/?h=am/fix-addrinfo-crash

Best regards,
Andrey Mikhaylov

> On 13 Sep 2022, at 14:41, Houman <houmie at gmail.com> wrote:
> 
> My existing Wireguard iOS implementation stopped working after
> upgrading to Xcode 14 today.
> When trying to connect to servers that support only IPv4, then it's
> fine. But if the server supports both IPv6 and IPv4 then the tunnel
> crashes:
> 
> This IPv6 extension in
> wireguard-apple/Sources/WireGuardKit/IPAddress+AddrInfo.swift crashes
> with a Fatal Error at addrInfo.ai_addr.withMemoryRebound()
> 
> The whole extension below:
> 
> extension IPv6Address {
>    init?(addrInfo: addrinfo) {
>        guard addrInfo.ai_family == AF_INET6 else { return nil }
> 
>        let addressData = addrInfo.ai_addr.withMemoryRebound(to:
> sockaddr_in6.self, capacity: MemoryLayout<sockaddr_in6>.size) { ptr ->
> Data in
>            return Data(bytes: &ptr.pointee.sin6_addr, count:
> MemoryLayout<in6_addr>.size)
>        }
>        self.init(addressData)
>    }
> }
> 
> Has anyone else experienced this problem?
> 
> Thanks,


From houmie at gmail.com  Thu Sep 22 08:56:17 2022
From: houmie at gmail.com (Houman)
Date: Thu, 22 Sep 2022 09:56:17 +0100
Subject: Wireguard iOS crashes after upgrading to XCode 14
In-Reply-To: <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>
References: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
 <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>
Message-ID: <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>

Hi Andrej,

It works, well done!

A strange thing though, before your patch I was still able to connect
to the VPN server, if I changed the schema to Release instead of
Debug.  Now with your patch it also works under Debug schema, which is
fantastic.
What could be the technical reason that it still worked under Release?

And what will happen now, are you able to actually get this patch
released on the official repo? The repo hasn't been updated for a
year.  :-)

Thanks,
Houman


On Thu, 22 Sept 2022 at 09:31, Andrej Mihajlov <and at mullvad.net> wrote:
>
> Hi,
>
> I think we have a bug. If I am right, basically in both IPv4 and IPv6 extensions, withMemoryRebound takes capacity which is actually a number of instances of a given type (sockaddr_ variant) and not the byte size of a struct.
>
> Could you please patch your WireGuardKit with the following commit and see if it helps?
>
> https://git.zx2c4.com/wireguard-apple/commit/?h=am/fix-addrinfo-crash
>
> Best regards,
> Andrey Mikhaylov
>
> > On 13 Sep 2022, at 14:41, Houman <houmie at gmail.com> wrote:
> >
> > My existing Wireguard iOS implementation stopped working after
> > upgrading to Xcode 14 today.
> > When trying to connect to servers that support only IPv4, then it's
> > fine. But if the server supports both IPv6 and IPv4 then the tunnel
> > crashes:
> >
> > This IPv6 extension in
> > wireguard-apple/Sources/WireGuardKit/IPAddress+AddrInfo.swift crashes
> > with a Fatal Error at addrInfo.ai_addr.withMemoryRebound()
> >
> > The whole extension below:
> >
> > extension IPv6Address {
> >    init?(addrInfo: addrinfo) {
> >        guard addrInfo.ai_family == AF_INET6 else { return nil }
> >
> >        let addressData = addrInfo.ai_addr.withMemoryRebound(to:
> > sockaddr_in6.self, capacity: MemoryLayout<sockaddr_in6>.size) { ptr ->
> > Data in
> >            return Data(bytes: &ptr.pointee.sin6_addr, count:
> > MemoryLayout<in6_addr>.size)
> >        }
> >        self.init(addressData)
> >    }
> > }
> >
> > Has anyone else experienced this problem?
> >
> > Thanks,
>

From Jason at zx2c4.com  Thu Sep 22 09:38:16 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 22 Sep 2022 11:38:16 +0200
Subject: Wireguard iOS crashes after upgrading to XCode 14
In-Reply-To: <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>
References: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
 <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>
 <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>
Message-ID: <CAHmME9pZy+EYQbmrBi_5Ei191zJ_X3imSuZ_U766HhXp39MHbA@mail.gmail.com>

On 9/22/22, Houman <houmie at gmail.com> wrote:
> Hi Andrej,
>
> It works, well done!
>
> A strange thing though, before your patch I was still able to connect
> to the VPN server, if I changed the schema to Release instead of
> Debug.  Now with your patch it also works under Debug schema, which is
> fantastic.
> What could be the technical reason that it still worked under Release?
>
> And what will happen now, are you able to actually get this patch
> released on the official repo? The repo hasn't been updated for a
> year.  :-)
>

Yeah, I'll circle back Apple development at some point. No worries.

Jason

From houmie at gmail.com  Thu Sep 22 09:39:49 2022
From: houmie at gmail.com (Houman)
Date: Thu, 22 Sep 2022 10:39:49 +0100
Subject: Wireguard iOS crashes after upgrading to XCode 14
In-Reply-To: <CAHmME9pZy+EYQbmrBi_5Ei191zJ_X3imSuZ_U766HhXp39MHbA@mail.gmail.com>
References: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
 <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>
 <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>
 <CAHmME9pZy+EYQbmrBi_5Ei191zJ_X3imSuZ_U766HhXp39MHbA@mail.gmail.com>
Message-ID: <CABBZOskivNaYOWM3tZKhFnELApoP-FQ+CEioe59J2=4RbnSAOw@mail.gmail.com>

Sounds good, thanks, Jason.

On Thu, 22 Sept 2022 at 10:38, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> On 9/22/22, Houman <houmie at gmail.com> wrote:
> > Hi Andrej,
> >
> > It works, well done!
> >
> > A strange thing though, before your patch I was still able to connect
> > to the VPN server, if I changed the schema to Release instead of
> > Debug.  Now with your patch it also works under Debug schema, which is
> > fantastic.
> > What could be the technical reason that it still worked under Release?
> >
> > And what will happen now, are you able to actually get this patch
> > released on the official repo? The repo hasn't been updated for a
> > year.  :-)
> >
>
> Yeah, I'll circle back Apple development at some point. No worries.
>
> Jason

From and at mullvad.net  Thu Sep 22 09:44:31 2022
From: and at mullvad.net (Andrej Mihajlov)
Date: Thu, 22 Sep 2022 11:44:31 +0200
Subject: Wireguard iOS crashes after upgrading to XCode 14
In-Reply-To: <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>
References: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
 <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>
 <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>
Message-ID: <6E42D7CE-E03C-4D87-B9CD-182567D9C087@mullvad.net>

Hi Houman,

I believe that the crash coming from withMemoryRebound is actually assertion (assert()). Very often assertions are stripped out from release builds, so I guess it could be the reason why it just worked in release builds.

Jason has already replied in regards of releasing an update.

Best regards,
Andrej

> On 22 Sep 2022, at 10:56, Houman <houmie at gmail.com> wrote:
> 
> Hi Andrej,
> 
> It works, well done!
> 
> A strange thing though, before your patch I was still able to connect
> to the VPN server, if I changed the schema to Release instead of
> Debug.  Now with your patch it also works under Debug schema, which is
> fantastic.
> What could be the technical reason that it still worked under Release?
> 
> And what will happen now, are you able to actually get this patch
> released on the official repo? The repo hasn't been updated for a
> year.  :-)
> 
> Thanks,
> Houman
> 
> 
> On Thu, 22 Sept 2022 at 09:31, Andrej Mihajlov <and at mullvad.net> wrote:
>> 
>> Hi,
>> 
>> I think we have a bug. If I am right, basically in both IPv4 and IPv6 extensions, withMemoryRebound takes capacity which is actually a number of instances of a given type (sockaddr_ variant) and not the byte size of a struct.
>> 
>> Could you please patch your WireGuardKit with the following commit and see if it helps?
>> 
>> https://git.zx2c4.com/wireguard-apple/commit/?h=am/fix-addrinfo-crash
>> 
>> Best regards,
>> Andrey Mikhaylov
>> 
>>> On 13 Sep 2022, at 14:41, Houman <houmie at gmail.com> wrote:
>>> 
>>> My existing Wireguard iOS implementation stopped working after
>>> upgrading to Xcode 14 today.
>>> When trying to connect to servers that support only IPv4, then it's
>>> fine. But if the server supports both IPv6 and IPv4 then the tunnel
>>> crashes:
>>> 
>>> This IPv6 extension in
>>> wireguard-apple/Sources/WireGuardKit/IPAddress+AddrInfo.swift crashes
>>> with a Fatal Error at addrInfo.ai_addr.withMemoryRebound()
>>> 
>>> The whole extension below:
>>> 
>>> extension IPv6Address {
>>>   init?(addrInfo: addrinfo) {
>>>       guard addrInfo.ai_family == AF_INET6 else { return nil }
>>> 
>>>       let addressData = addrInfo.ai_addr.withMemoryRebound(to:
>>> sockaddr_in6.self, capacity: MemoryLayout<sockaddr_in6>.size) { ptr ->
>>> Data in
>>>           return Data(bytes: &ptr.pointee.sin6_addr, count:
>>> MemoryLayout<in6_addr>.size)
>>>       }
>>>       self.init(addressData)
>>>   }
>>> }
>>> 
>>> Has anyone else experienced this problem?
>>> 
>>> Thanks,
>> 


From houmie at gmail.com  Thu Sep 22 09:46:34 2022
From: houmie at gmail.com (Houman)
Date: Thu, 22 Sep 2022 10:46:34 +0100
Subject: Wireguard iOS crashes after upgrading to XCode 14
In-Reply-To: <6E42D7CE-E03C-4D87-B9CD-182567D9C087@mullvad.net>
References: <CABBZOsks3ZnpcURYHSQcaWCe8ETY21zitPY5TvtTaAm38DT5EA@mail.gmail.com>
 <834CB179-958C-4C0E-8B17-9918C8A992FB@mullvad.net>
 <CABBZOs=9VVSDEGPw1eQWmusJotA5toLCn1-uNQeZ+moPthAOxg@mail.gmail.com>
 <6E42D7CE-E03C-4D87-B9CD-182567D9C087@mullvad.net>
Message-ID: <CABBZOsk1BAVCSnYL=HXpnf6ncPJunmuumENQ76E+aV82HTaMuw@mail.gmail.com>

Thank you Andrej for explaining the reason. It makes sense.

Kind regards,
Houman

On Thu, 22 Sept 2022 at 10:44, Andrej Mihajlov <and at mullvad.net> wrote:
>
> Hi Houman,
>
> I believe that the crash coming from withMemoryRebound is actually assertion (assert()). Very often assertions are stripped out from release builds, so I guess it could be the reason why it just worked in release builds.
>
> Jason has already replied in regards of releasing an update.
>
> Best regards,
> Andrej
>
> > On 22 Sep 2022, at 10:56, Houman <houmie at gmail.com> wrote:
> >
> > Hi Andrej,
> >
> > It works, well done!
> >
> > A strange thing though, before your patch I was still able to connect
> > to the VPN server, if I changed the schema to Release instead of
> > Debug.  Now with your patch it also works under Debug schema, which is
> > fantastic.
> > What could be the technical reason that it still worked under Release?
> >
> > And what will happen now, are you able to actually get this patch
> > released on the official repo? The repo hasn't been updated for a
> > year.  :-)
> >
> > Thanks,
> > Houman
> >
> >
> > On Thu, 22 Sept 2022 at 09:31, Andrej Mihajlov <and at mullvad.net> wrote:
> >>
> >> Hi,
> >>
> >> I think we have a bug. If I am right, basically in both IPv4 and IPv6 extensions, withMemoryRebound takes capacity which is actually a number of instances of a given type (sockaddr_ variant) and not the byte size of a struct.
> >>
> >> Could you please patch your WireGuardKit with the following commit and see if it helps?
> >>
> >> https://git.zx2c4.com/wireguard-apple/commit/?h=am/fix-addrinfo-crash
> >>
> >> Best regards,
> >> Andrey Mikhaylov
> >>
> >>> On 13 Sep 2022, at 14:41, Houman <houmie at gmail.com> wrote:
> >>>
> >>> My existing Wireguard iOS implementation stopped working after
> >>> upgrading to Xcode 14 today.
> >>> When trying to connect to servers that support only IPv4, then it's
> >>> fine. But if the server supports both IPv6 and IPv4 then the tunnel
> >>> crashes:
> >>>
> >>> This IPv6 extension in
> >>> wireguard-apple/Sources/WireGuardKit/IPAddress+AddrInfo.swift crashes
> >>> with a Fatal Error at addrInfo.ai_addr.withMemoryRebound()
> >>>
> >>> The whole extension below:
> >>>
> >>> extension IPv6Address {
> >>>   init?(addrInfo: addrinfo) {
> >>>       guard addrInfo.ai_family == AF_INET6 else { return nil }
> >>>
> >>>       let addressData = addrInfo.ai_addr.withMemoryRebound(to:
> >>> sockaddr_in6.self, capacity: MemoryLayout<sockaddr_in6>.size) { ptr ->
> >>> Data in
> >>>           return Data(bytes: &ptr.pointee.sin6_addr, count:
> >>> MemoryLayout<in6_addr>.size)
> >>>       }
> >>>       self.init(addressData)
> >>>   }
> >>> }
> >>>
> >>> Has anyone else experienced this problem?
> >>>
> >>> Thanks,
> >>
>

From harald.dunkel at aixigo.com  Thu Sep 22 11:29:07 2022
From: harald.dunkel at aixigo.com (Harald Dunkel)
Date: Thu, 22 Sep 2022 13:29:07 +0200
Subject: MacOS app update needed
In-Reply-To: <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
 <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>
Message-ID: <235c4ba6-95cf-2532-1b7d-3754cc4f255d@aixigo.com>

I would love to have an update for Wireguard on MacOS and Ios.

Maybe Apple would include wireguard into MacOS' kernel as well,
if there is sufficient demand for this feature? Make yourself
heard at Apple's feedback page for MacOS.


Regards
Harri

From Jason at zx2c4.com  Thu Sep 22 11:33:40 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 22 Sep 2022 13:33:40 +0200
Subject: MacOS app update needed
In-Reply-To: <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
Message-ID: <CAHmME9rHYbDBU8Y0cs1YnGKqqxB7SdyoGjwE1n4Hd_1=GZ6ADg@mail.gmail.com>

On Wed, Sep 21, 2022 at 9:55 AM Houman <houmie at gmail.com> wrote:
>
> Hi Simon,
>
> Not only that, even the repo
> https://github.com/WireGuard/wireguard-apple hasn't been updated since
> 27 Sep 2021.
> There are a number of useful contributions in the form of pull
> requests waiting there to be approved for over 8 months.
>
> The project feels abandoned, which is such a shame.

It really isn't abandoned. Please don't worry. No reason to start freaking out.

From Jason at zx2c4.com  Thu Sep 22 11:34:29 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 22 Sep 2022 13:34:29 +0200
Subject: MacOS app update needed
In-Reply-To: <235c4ba6-95cf-2532-1b7d-3754cc4f255d@aixigo.com>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
 <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>
 <235c4ba6-95cf-2532-1b7d-3754cc4f255d@aixigo.com>
Message-ID: <CAHmME9pnz8zWOLL+1zCPhEPyxiyM-mGDE9x6p_xqQ3q8CxkyMg@mail.gmail.com>

On Thu, Sep 22, 2022 at 1:32 PM Harald Dunkel <harald.dunkel at aixigo.com> wrote:
> Maybe Apple would include wireguard into MacOS' kernel as well,
> if there is sufficient demand for this feature? Make

I offered to do a kernel implementation for them, but they never got back to me.

From Jason at zx2c4.com  Thu Sep 22 11:43:12 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 22 Sep 2022 13:43:12 +0200
Subject: MacOS app update needed
In-Reply-To: <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
 <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>
Message-ID: <CAHmME9rd4g0EkPQqXX9vViHRuU8uaGkENNNa+TsBi3C_QNHbxw@mail.gmail.com>

On Wed, Sep 21, 2022 at 10:22 AM Bruno <bandry at ut1.org> wrote:
>
> Hi,
>
> Windows Client project don't feel alive either. Last commit has 6 months
> and last release is 9 month old.
>
> Same, here https://git.zx2c4.com/wireguard-windows/log/ and here
> https://github.com/WireGuard/wireguard-windows
>
> Version 0.5.3 works well, but I suppose it can be even better!

That seems pretty uncalled for. Folks asking for a wireguard-apple
update have good reason to do so -- there are outstanding bugs and
pull requests. But for wireguard-windows/wireguard-nt? C'mon now --
that's received some *extremely* active development, stabilizing after
nearly weekly updates for some time. Are there outstanding pull
requests for it? So your note here really isn't appreciated. The
WireGuard project doesn't churn out code and updates just for the sake
of writing code and doing updates. Things need to have rationale.
There will be updates to wireguard-windows/wireguard-nt at some point
when development makes sense there. But right now? Is there something
pending? Instead maybe be thankful that that software has reached a
point of stability where project development energies can go into more
pressing tasks, such as wireguard-apple.

Jason

From Jason at zx2c4.com  Thu Sep 22 11:48:13 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 22 Sep 2022 13:48:13 +0200
Subject: MacOS app update needed
In-Reply-To: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
Message-ID: <CAHmME9o1psix3jGC5tx81dG_7D+WVrBhjYSho-_tLGu=S7H+1Q@mail.gmail.com>

On Wed, Sep 21, 2022 at 9:31 AM Simon Karberg <simon.karberg at agillic.com> wrote:
>
> Hi,
>
> I've been testing the Domain Search functionality on all 3 OS'
> (Windows, Mac & Linux) and the setting:
>
> DNS=<dns server>, <search domains>
> Is only being applied on Windows & Linux.
>
> Further testing on MacOS I've found that the homebrew installation works.
> wiregurd-go is version 0.0.20220316 and wireguard-tools is version 1.0.20210914
>
> The App Store app is version:
> App: 1.0.15 (26)
> Go backend: 2ef39d47

Huh, that's surprising. This was added a few years ago with 9231c035
("global: support DNS search domains"), so it definitely *should* be
supported. Might be a bug with the network config from
PacketTunnelSettingsGenerator. I'll look into this when circling back
to wireguard-apple development. Thanks for mentioning it.

Jason

From bandry at ut1.org  Thu Sep 22 13:26:11 2022
From: bandry at ut1.org (Bruno)
Date: Thu, 22 Sep 2022 15:26:11 +0200
Subject: MacOS app update needed
In-Reply-To: <1980318156.4949115.1663848249035.JavaMail.zimbra@donzis.com>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
 <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>
 <CAHmME9rd4g0EkPQqXX9vViHRuU8uaGkENNNa+TsBi3C_QNHbxw@mail.gmail.com>
 <1980318156.4949115.1663848249035.JavaMail.zimbra@donzis.com>
Message-ID: <622e8ce5-82bc-c633-4cfa-ebd2a42a8fc7@ut1.org>

Hi,

I'm sorry if my question was awkward. Like I said, it works well.

I never asked for useless development. I'm just surprised last commits 
are not included in a release.

We also had a constructive chat in November (with Diab Neiroukh) on this 
list. You made an appreciated change, but the question remained opened.

I really admire your work and simply asked if something was planned. I 
understand you have priorities and won't bother you any longer.

Regards.

Bruno

Le 22/09/2022 ? 14:04, Lewis Donzis a ?crit?:
> ----- On Sep 22, 2022, at 6:43 AM, Jason A. Donenfeld Jason at zx2c4.com wrote:
>> On Wed, Sep 21, 2022 at 10:22 AM Bruno <bandry at ut1.org> wrote:
>>>
>>> Hi,
>>>
>>> Windows Client project don't feel alive either. Last commit has 6 months
>>> and last release is 9 month old.
>>>
>>> Same, here https://git.zx2c4.com/wireguard-windows/log/ and here
>>> https://github.com/WireGuard/wireguard-windows
>>>
>>> Version 0.5.3 works well, but I suppose it can be even better!
>>
>> That seems pretty uncalled for. Folks asking for a wireguard-apple
>> update have good reason to do so -- there are outstanding bugs and
>> pull requests. But for wireguard-windows/wireguard-nt? C'mon now --
>> that's received some *extremely* active development, stabilizing after
>> nearly weekly updates for some time. Are there outstanding pull
>> requests for it? So your note here really isn't appreciated. The
>> WireGuard project doesn't churn out code and updates just for the sake
>> of writing code and doing updates. Things need to have rationale.
>> There will be updates to wireguard-windows/wireguard-nt at some point
>> when development makes sense there. But right now? Is there something
>> pending? Instead maybe be thankful that that software has reached a
>> point of stability where project development energies can go into more
>> pressing tasks, such as wireguard-apple.
>>
>> Jason
> 
> I could not agree more.  What a world we live in where code that hasn't been touched for a few months is considered stale, rather than being rewarded and appreciated for reliability and stability.  Jason, congratulations on not needing to touch that code for six months!  Much of the beauty of Wireguard is its simplicity, to the point that it can be done "right", and it really shouldn't need to be touched!
> 

From Jason at zx2c4.com  Thu Sep 22 13:49:03 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 22 Sep 2022 15:49:03 +0200
Subject: MacOS app update needed
In-Reply-To: <622e8ce5-82bc-c633-4cfa-ebd2a42a8fc7@ut1.org>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
 <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>
 <CAHmME9rd4g0EkPQqXX9vViHRuU8uaGkENNNa+TsBi3C_QNHbxw@mail.gmail.com>
 <1980318156.4949115.1663848249035.JavaMail.zimbra@donzis.com>
 <622e8ce5-82bc-c633-4cfa-ebd2a42a8fc7@ut1.org>
Message-ID: <Yyxnz2OJjONLKrSm@zx2c4.com>

On Thu, Sep 22, 2022 at 03:26:11PM +0200, Bruno wrote:
> We also had a constructive chat in November (with Diab Neiroukh) on this 
> list. You made an appreciated change, but the question remained opened.

The change from that discussion is in 0.5.3:
https://git.zx2c4.com/wireguard-windows/commit/?id=8120d07dd5fc9a5e545419fe13490086ce920f31

From wireguard-mail at chil.at  Thu Sep 22 20:54:20 2022
From: wireguard-mail at chil.at (Christoph Loesch)
Date: Thu, 22 Sep 2022 22:54:20 +0200
Subject: WireGuard App on Android allows only one connection simultaneously
In-Reply-To: <30014af580cd42edba0121c0d6b99add@rozman.si>
References: <62cc526e-7b02-3529-d575-87434af15bd3@chil.at>
 <30014af580cd42edba0121c0d6b99add@rozman.si>
Message-ID: <2bcbfaf2-5fb0-af88-8417-a90b5fe57a08@chil.at>

Hi,

(thanks to mohammad who pointed me in the right direction)

Am 21.09.2022 um 10:29 schrieb Simon Rozman:
> Unfortunately, this is a limitation of Android OS supporting only 1 (one) VPN connection at a time.

Note: Limitation of not rooted devices. The app works with userspace backend until you root your device.

Once rooted you need to allow root-access to the app (it asks for root if your device is rooted) and then you can enable the use of kernel module/backend in advanced settings.
Then enable option for multiple tunnels at the same time.
Maybe it's worth to put hint for that in the app?

Works great so far.
(Sure, you have to keep an eye on used IP-ranges/routes that could be same on different tunnels what could result in unexpected behaviour when used simultaneously.)

Thank you very much and kind regards!
Christoph


From powergame_coder2 at yahoo.com  Wed Sep 28 09:32:04 2022
From: powergame_coder2 at yahoo.com (Mehdi Haghgoo)
Date: Wed, 28 Sep 2022 09:32:04 +0000 (UTC)
Subject: Wireguard does not work in Iran
References: <561370843.2818033.1664357524603.ref@mail.yahoo.com>
Message-ID: <561370843.2818033.1664357524603@mail.yahoo.com>

Hi,

It seems that Wireguard does not work at all in Iran.
I used to use it with nmcli on Linux, but recently it just does not work, even with ADSL Internet (Mobile internet is mainly shut down).

I suspect it is not because UDP is completely blocked, because I see some other VPNs are working with UDP. Could the co

Are there any suggestions to make Wireguard work under recent harsh Internet crackdowns?

An example of the Wireguard conf I used to import into NetworkManager is as follows:

[Interface]
PrivateKey = xxxxxxxxxxxx
Address = 10.2.0.2/32
DNS = 10.2.0.1

[Peer]
PublicKey = xxxxxxxxxxxxxxxx
AllowedIPs = 0.0.0.0/0
Endpoint = x.x.x.x:51820

Best regards,
M.

From mgsb81 at gmail.com  Thu Sep  8 13:50:08 2022
From: mgsb81 at gmail.com (Michael Brookes)
Date: Thu, 08 Sep 2022 13:50:08 -0000
Subject: Constant stream of handshake for peer did not complete
Message-ID: <CABfcST-uzN3JJ0vB04s4TSfSbz18Ngn9pn+41iN_g62XWoAtUw@mail.gmail.com>

Hi

I have one wg endpoint which is CentOS 7.9.2009
(3.10.0-1160.71.1.el7.x86_64) with kmod-wireguard
9:1.0.20220627-1.el7_9.elrepo installed. Has about 300ish peers.

We have one, there could be more, cases of wireguard logging on the
other peer (typically laptops, I've seen this happen on Mac using the
app and Ubuntu)

Handshake for peer 6 ... did not complete after 5 seconds, retrying (try 4)

The handshake on the CentOS end never updates and of course the tunnel
doesn't work on the Mac/Ubuntu laptop.

To get the tunnel working again all I do is on the CentOS end remove
and add the peer, and the tunnel suddenly springs to life and traffic
flows normally.

I've since enabled debug on the CentOS end and see a constant stream of:

Handshake for peer 6 ... did not complete after 5 seconds, retrying (try 4)

Since I enabled debugging ~200 different peers have logged that.
Also see this - invalid address - a few times too for different peers:

Handshake for peer 1809 ((invalid address)) did not complete after 5
seconds, retrying (try 5)

Is this expected debug output for a setup where you have a CentOS
server with peers which are all laptops? i.e. the CentOS end is trying
to initiate the handshake and the laptop is off/wireguard app turned
off.

Is it down to some UDP traffic potentially being dropped? Some network
card tweaks needed?

Any help greatly appreciated

From weichen302 at zoho.com  Sat Sep 10 11:34:52 2022
From: weichen302 at zoho.com (Wei Chen)
Date: Sat, 10 Sep 2022 11:34:52 -0000
Subject: Iptables WireGuard obfuscation extension
Message-ID: <183272e3203.12ada1173180167.8469340361616836666@zoho.com>

Hi,

Jason once suggested use a netfilter module for obfuscation[1]. Here is one.

https://github.com/infinet/xt_wgobfs

It uses SipHash 1-2 to generate pseudo-random numbers in a reproducible way.
Sender and receiver share a siphash secret key. Sender creates and receiver
re-creates identical siphash output, if input is same. These siphash outputs
are used for obfuscation.

- The first 16 bytes of WG message is obfuscated.
- The mac2 field is also obfuscated if it is all zeros.
- Padding WG message with random bytes, which also has random length. They are
  from kernel get_random_bytes_wait() though.
- Drop 80% of keepalive message at random. Again randomness is from kernel.
- Change the Diffserv field to zero.

Tested working on Alpine linux kernel 5.15 and CentOS 7 kernel 3.10.

Performance test in two Alpine VMs running on same host. Each VM has 1 CPU and
256 MB RAM. Iperf3 results 1.1Gbits/s without,vs 860Mbits/s with obfuscation.


Wei

1. https://lists.zx2c4.com/pipermail/wireguard/2021-September/007155.html

From marcel at linux-ng.de  Tue Sep 13 19:37:33 2022
From: marcel at linux-ng.de (marcel at linux-ng.de)
Date: Tue, 13 Sep 2022 19:37:33 +0000
Subject: Possible performance impact of queuing?
Message-ID: <46fae16c62151cf55e7b357e8dc0df94@linux-ng.de>

Hi there,

I was just testing wireguard performance on a new server machine (with lots of cores) and got lower
performance than expected.
However a lot of kernel processes were spawned only using CPUs up to 20% (but not higher).
That got me thinking about a possible cause.

I remembered, that some time ago I noticed a similar behavior for dm-crypt and while investigating
further I found this detailed analysis:
https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
It showed, that the kernel internal queuing has a huge impact on throughput and latency (and
there's a fix/option for that in newer kernel releases, s. end of above blog article (search for
"merged")).

So I wondered if the wireguard code may face the same challenge?
I had a quick look at the code and to me (as a non kernel developer) it looks like it could be
worth a try, to adapt and benchmark the changes made for dm-crypt.

I hope someone with more knowledge about wireguard / kernel internals can comment on that.
(I know wireguard is one of the fastest VPN solutions around, but what if it could be even faster?
:-) )

Bye, Marcel

From jan.petrischkeit at hochschule-stralsund.de  Tue Sep 20 13:16:30 2022
From: jan.petrischkeit at hochschule-stralsund.de (Jan Petrischkeit)
Date: Tue, 20 Sep 2022 15:16:30 +0200
Subject: wireguard-windows: Wireguard does not start a previously activated
 tunnel from time to time
Message-ID: <4e093a02-723d-22ff-fd33-f220ac24e19e@hochschule-stralsund.de>

Dear Wireguard Community,

I have the problem that Wireguard on some systems and there only from 
time to time forgets to activate the tunnel at system startup.
Mainly this happens after an update of the wireguard client or changes 
to the client config. If an admin then reactivates the tunnel, it will 
(mostly) run on the following system starts.
My users have no way to disable the tunnel. At least in the past, but 
the problem has come up so often now that I've started making the 
LimitedOperatorGUI available to them to be able to activate the tunnel.

One user (Denis Brodbeck @ 2021-07-06 6:18 UTC) had already sent a mail 
to this list about this problem (Title: "wireguard-windows: client 
forgets after restart that there was an activated tunnel before and 
won't activate said tunnel anymore"), my environment and experiences 
pretty much match his descriptions.
However, I am fairly unexperienced with mailing lists, so I don't know 
how to directly reply to that entry.

However, I have two systems so far where the tunnel never starts 
automatically on boot. On these systems I noticed that Windows notes a 
corresponding entry in the event viewer (translated from german to english):

Event 7023, ServiceControlManager: The service 
"WireGuardTunnel$HOST-WG2" was terminated with the following error: The 
requested name is valid, but no data of the requested type was found.

If I set the tunnel's service to Delayed Start, it works, but usually 
only some time after the user logs in. It also works if I start the 
service manually before Delayed Start becomes active.
If I don't set the startup type of the tunnel to "Delayed start", the 
service entry for the tunnel disappears from the services list after the 
next restart (and the error message in the event viewer).


Hope someone has some pointers on how to resolve this.

Cheers,
Jan Petrischkeit


From wireguard at bulletin.elitemail.org  Wed Sep 21 02:18:38 2022
From: wireguard at bulletin.elitemail.org (wireguard at bulletin.elitemail.org)
Date: Wed, 21 Sep 2022 02:18:38 +0000
Subject: Android: Support for Material You Themed Icon?
Message-ID: <848c8979-89e7-46af-a7b2-42aec914bccf@www.fastmail.com>

This would be useful for my partial color blindness (and others who are similarly color vision deficient) as it would  provide a base to improve the contrast of the icon against a light/dark theme background (a monochromatic icon layer and a touch of XML): 

https://developer.android.com/develop/ui/views/launch/icon_design_adaptive


From wireguard at bulletin.elitemail.org  Wed Sep 21 04:09:56 2022
From: wireguard at bulletin.elitemail.org (wireguard at bulletin.elitemail.org)
Date: Wed, 21 Sep 2022 04:09:56 +0000
Subject: APK outside of Play Store?
Message-ID: <517b5e80-d3ac-4829-9096-1415ecad5aa4@www.fastmail.com>

For users who prefer to avoid Play Store as a delivery channel, is there an official pre-built APK available? Such users are typically steered towards APKPure/APKMirror/F-Droid with questionabl authenticity and (in the case of F-Droid) the prospect of old build dependencies built on an EOL OS (Strech). Aurora is an option, though a dev provided build (with accompanying checksum/signing cert fingerprint) would be preferable. 

From lew at perftech.com  Thu Sep 22 12:04:09 2022
From: lew at perftech.com (Lewis Donzis)
Date: Thu, 22 Sep 2022 07:04:09 -0500 (CDT)
Subject: MacOS app update needed
In-Reply-To: <CAHmME9rd4g0EkPQqXX9vViHRuU8uaGkENNNa+TsBi3C_QNHbxw@mail.gmail.com>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CABBZOs=bkOWQv09UQJnf18xVGAq_o6O+Ar+asMKoXtghcQvnog@mail.gmail.com>
 <ee65e180-eef5-b882-58ab-8a1188a38a09@ut1.org>
 <CAHmME9rd4g0EkPQqXX9vViHRuU8uaGkENNNa+TsBi3C_QNHbxw@mail.gmail.com>
Message-ID: <1980318156.4949115.1663848249035.JavaMail.zimbra@donzis.com>

----- On Sep 22, 2022, at 6:43 AM, Jason A. Donenfeld Jason at zx2c4.com wrote:
> On Wed, Sep 21, 2022 at 10:22 AM Bruno <bandry at ut1.org> wrote:
>>
>> Hi,
>>
>> Windows Client project don't feel alive either. Last commit has 6 months
>> and last release is 9 month old.
>>
>> Same, here https://git.zx2c4.com/wireguard-windows/log/ and here
>> https://github.com/WireGuard/wireguard-windows
>>
>> Version 0.5.3 works well, but I suppose it can be even better!
> 
> That seems pretty uncalled for. Folks asking for a wireguard-apple
> update have good reason to do so -- there are outstanding bugs and
> pull requests. But for wireguard-windows/wireguard-nt? C'mon now --
> that's received some *extremely* active development, stabilizing after
> nearly weekly updates for some time. Are there outstanding pull
> requests for it? So your note here really isn't appreciated. The
> WireGuard project doesn't churn out code and updates just for the sake
> of writing code and doing updates. Things need to have rationale.
> There will be updates to wireguard-windows/wireguard-nt at some point
> when development makes sense there. But right now? Is there something
> pending? Instead maybe be thankful that that software has reached a
> point of stability where project development energies can go into more
> pressing tasks, such as wireguard-apple.
> 
> Jason

I could not agree more.  What a world we live in where code that hasn't been touched for a few months is considered stale, rather than being rewarded and appreciated for reliability and stability.  Jason, congratulations on not needing to touch that code for six months!  Much of the beauty of Wireguard is its simplicity, to the point that it can be done "right", and it really shouldn't need to be touched!

From kc at omnigroup.com  Sat Sep 24 01:28:21 2022
From: kc at omnigroup.com (Ken Case)
Date: Fri, 23 Sep 2022 18:28:21 -0700
Subject: MacOS app update needed
In-Reply-To: <CAHmME9o1psix3jGC5tx81dG_7D+WVrBhjYSho-_tLGu=S7H+1Q@mail.gmail.com>
References: <CALDyVtsgMjH1YqrTrosDVU2khC9iEgMgUYDd8D65+h-K54y2fA@mail.gmail.com>
 <CAHmME9o1psix3jGC5tx81dG_7D+WVrBhjYSho-_tLGu=S7H+1Q@mail.gmail.com>
Message-ID: <3EAF348D-C304-4048-81CC-98110AD1BCAC@omnigroup.com>


> On Sep 22, 2022, at 04:48, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> On Wed, Sep 21, 2022 at 9:31 AM Simon Karberg <simon.karberg at agillic.com> wrote:
>> 
>> Hi,
>> 
>> I've been testing the Domain Search functionality on all 3 OS'
>> (Windows, Mac & Linux) and the setting:
>> 
>> DNS=<dns server>, <search domains>
>> Is only being applied on Windows & Linux.
>> 
>> Further testing on MacOS I've found that the homebrew installation works.
>> wiregurd-go is version 0.0.20220316 and wireguard-tools is version 1.0.20210914
>> 
>> The App Store app is version:
>> App: 1.0.15 (26)
>> Go backend: 2ef39d47
> 
> Huh, that's surprising. This was added a few years ago with 9231c035
> ("global: support DNS search domains"), so it definitely *should* be
> supported. Might be a bug with the network config from
> PacketTunnelSettingsGenerator. I'll look into this when circling back
> to wireguard-apple development. Thanks for mentioning it.
> 
> Jason
> 

Oh, I have a pretty simple patch that fixes this bug that I've been running locally for months. I keep meaning to figure out the right place to send it, but keep not having time to look up where that is. Patch included below, anyone is welcome to use it (attributed or not) or to direct me to send it somewhere else!

				Cheers,
				Ken

---

Subject: [PATCH] Qualify routed DNS queries based on search domains.

Rather than unconditionally routing all DNS queries through the
associated tunnel's DNS, only route queries when no search domains
have been specified. When search domains _have_ been specified, route
those domains to the tunnel's DNS but let other domains continue to be
routed to other network interfaces.
---
Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift b/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift
index c53a82c..5b7f63c 100644
--- a/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift
+++ b/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift
@@ -88,7 +88,13 @@ class PacketTunnelSettingsGenerator {
            let dnsSettings = NEDNSSettings(servers: dnsServerStrings)
            dnsSettings.searchDomains = tunnelConfiguration.interface.dnsSearch
            if !tunnelConfiguration.interface.dns.isEmpty {
-                dnsSettings.matchDomains = [""] // All DNS queries must first go through the tunnel's DNS
+                if tunnelConfiguration.interface.dnsSearch.isEmpty {
+                    // Since no search domains were listed, use this tunnel's DNS for all queries
+                    dnsSettings.matchDomains = [""]
+                } else {
+                    // Only use this tunnel for the listed search domains
+                    dnsSettings.matchDomains = tunnelConfiguration.interface.dnsSearch
+                }
            }
            networkSettings.dnsSettings = dnsSettings
        }
--  2.37.0 (Apple Git-136)


From coot at coot.me  Sun Sep 25 11:20:08 2022
From: coot at coot.me (coot at coot.me)
Date: Sun, 25 Sep 2022 11:20:08 +0000
Subject: WireGuard invalid MAC
Message-ID: <tc_RJxAHLCkuwnH-zzqG_kRpINdKQPkHV2EcHxd9Hvg35zKUqTjSD1enVM8UAEBeURm-4aBHxJEadNfVqn7ZRxyV2BAKrarPa5cL_hKhpB4=@coot.me>

Hello,

I configured wireguard so I can access my home server from a laptop.

When the laptop is using its eth0 interface to transport wireguard protocol messages it works fine, but when I switch it off and use wlan0 (which is using a different ISP), on the server side the kernel logs:

Keypair 20 destroyed for peer 2
Keypair 21 created for peer 2
Invalid MAC of handshake, dropping packet from ...

I am using a ddns to setup the endpoint on the laptop.  It's not a connection issue, as packets are reaching the server, but somehow the message authentication code (MAC) is not right after switching the interfaces.  Any clues how could I investigate this further?

Client config:
```
[Interface]
Address = 10.0.0.3/24
ListenPort = 5000
PrivateKey = <client_private_key>

[Peer]
PublicKey = <server_pubic_key>
AllowedIPs = 10.0.0.1/32
Endpoint = <dynamic domain name>:5000
```

Server config:
```
[Interface]
Address = 10.0.0.1/24
ListenPort = 5000
PrivateKey = <server_private_key>

[Peer]
PublicKey = <client_public_key>
AllowedIPs = 10.0.0.3/32
```

When the laptop is using wlan0, the server receives a packet `Handshake Initiation`, which is not replied.  When the laptop is using eth0 it just sends messages of type `Transport Data` (both observed with a tcpdump).

Regards,
Marcin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 509 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220925/eac4474c/attachment.sig>

From rm at romanrm.net  Wed Sep 28 11:33:56 2022
From: rm at romanrm.net (Roman Mamedov)
Date: Wed, 28 Sep 2022 16:33:56 +0500
Subject: Iptables WireGuard obfuscation extension
In-Reply-To: <183272e3203.12ada1173180167.8469340361616836666@zoho.com>
References: <183272e3203.12ada1173180167.8469340361616836666@zoho.com>
Message-ID: <20220928163356.183baef9@nvm>

On Sat, 10 Sep 2022 06:34:42 -0500
Wei Chen <weichen302 at zoho.com> wrote:

> Hi,
> 
> Jason once suggested use a netfilter module for obfuscation[1]. Here is one.
> 
> https://github.com/infinet/xt_wgobfs
> 
> It uses SipHash 1-2 to generate pseudo-random numbers in a reproducible way.
> Sender and receiver share a siphash secret key. Sender creates and receiver
> re-creates identical siphash output, if input is same. These siphash outputs
> are used for obfuscation.
> 
> - The first 16 bytes of WG message is obfuscated.
> - The mac2 field is also obfuscated if it is all zeros.
> - Padding WG message with random bytes, which also has random length. They are
>   from kernel get_random_bytes_wait() though.
> - Drop 80% of keepalive message at random. Again randomness is from kernel.
> - Change the Diffserv field to zero.
> 
> Tested working on Alpine linux kernel 5.15 and CentOS 7 kernel 3.10.
> 
> Performance test in two Alpine VMs running on same host. Each VM has 1 CPU and
> 256 MB RAM. Iperf3 results 1.1Gbits/s without,vs 860Mbits/s with obfuscation.

Hello,

Are you the author, so we can ask questions about it?

The "Usage" section speaks of "server" and "client". However in the WG world
there's not really a server or client per se, but all WG network members are
peers. As such, is it possible to propose an universal set of iptables rules
that would be fine to use on any network node?

As I understand, all INPUT packets to our local --dport need to be --unobfs,
and all OUTPUT packets from us to any other node need to be --obfs. Right?

-- 
With respect,
Roman

From Jason at zx2c4.com  Wed Sep 28 16:35:09 2022
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 28 Sep 2022 18:35:09 +0200
Subject: Iptables WireGuard obfuscation extension
In-Reply-To: <183272e3203.12ada1173180167.8469340361616836666@zoho.com>
References: <183272e3203.12ada1173180167.8469340361616836666@zoho.com>
Message-ID: <YzR3vcZhSjU2eRqB@zx2c4.com>

Hey Wei,

On Sat, Sep 10, 2022 at 06:34:42AM -0500, Wei Chen wrote:
> Hi,
> 
> Jason once suggested use a netfilter module for obfuscation[1]. Here is one.
> 
> https://github.com/infinet/xt_wgobfs
> 
> It uses SipHash 1-2 to generate pseudo-random numbers in a reproducible way.
> Sender and receiver share a siphash secret key. Sender creates and receiver
> re-creates identical siphash output, if input is same. These siphash outputs
> are used for obfuscation.
> 
> - The first 16 bytes of WG message is obfuscated.
> - The mac2 field is also obfuscated if it is all zeros.
> - Padding WG message with random bytes, which also has random length. They are
>   from kernel get_random_bytes_wait() though.
> - Drop 80% of keepalive message at random. Again randomness is from kernel.
> - Change the Diffserv field to zero.
> 
> Tested working on Alpine linux kernel 5.15 and CentOS 7 kernel 3.10.
> 
> Performance test in two Alpine VMs running on same host. Each VM has 1 CPU and
> 256 MB RAM. Iperf3 results 1.1Gbits/s without,vs 860Mbits/s with obfuscation.

This is super cool! I'm very glad to see that you've made this.

A couple considerations for improvement (take them or leave them):

- Instead of using siphash, if you can make use of 64 bytes of
  randomness at a time, you might be able to get away with chacha8 (or
  even lower). The input to chacha20 is typically a 256 bit key and a
  nonce, but because we don't care about the cryptographic security here
  -- wireguard handles that part -- we can play fast and lose, and make
  our threat model, "would be too computationally complex to detect in
  real time". Things become quite fun when you don't need real crypto.
  To that end, we could perhaps get away with using chacha8 instead of
  chacha20, and doing so with a 128-bit key. This then provides lots of
  input to chacha:

  * 16 bytes, where the second half of that key was
  * 16 bytes nonce (since it doesn't look like you need more than one block)
  * If you really want to play fast and loose: 32-byte constant...

  Again, this is awful cryptographic advice, but from a traffic analysis
  point of view, I doubt it makes a difference.

  On the other hand, if all you need is 16 bytes output, then I guess
  siphash gets the job done.

- get_random_bytes() is slow if all you need is a byte at a time. That
  computes 96 bytes and then throws away 88 bytes of it. Instead, you
  can use get_random_u32(), which batches, and throw away 3 bytes. Or, I
  think I'll add to kernel 6.1 get_random_u8(), which will waste
  nothing.

  But actually, do you really need to do that? Can't you just run chacha
  or siphash or whatever super fast non-cryptographic thing you have,
  and just have an incrementing nonce? Or, better, since those keepalive
  messages already have a suitably random poly1305 tag, just run siphash
  on that, and discard if the resultant first byte is high/low/whatever.

- If this is to ever go upstream, you might want to add a `--obfs-type
  N` parameter to the XT userspace library and the IPC struct, and make
  it mandatory. To begin, everybody would use `--obfs-type 1`, since
  that's all there is. But maybe overtime, you'll add a fake TCP mode or
  a fake QUIC mode or a fake HTML mode, and then the types will grow.
  This way, maintenance wise, you only have to send updates to the
  netfilter module in the kernel, and don't need to update the libxt
  part.

Jason

From simon at rozman.si  Wed Sep 28 17:23:32 2022
From: simon at rozman.si (Simon Rozman)
Date: Wed, 28 Sep 2022 17:23:32 +0000
Subject: wireguard-windows: Wireguard does not start a previously
 activated tunnel from time to time
In-Reply-To: <4e093a02-723d-22ff-fd33-f220ac24e19e@hochschule-stralsund.de>
References: <4e093a02-723d-22ff-fd33-f220ac24e19e@hochschule-stralsund.de>
Message-ID: <03b8866a0f8249c8883d9a0244ddea1b@rozman.si>

Hi,

> Event 7023, ServiceControlManager: The service "WireGuardTunnel$HOST-
> WG2" was terminated with the following error: The requested name is valid,
> but no data of the requested type was found.

The error message you are mentioning is WSANO_DATA 11004 which is related to DNS resolution problems. Which is kind of expected early in the boot process when the Dnscache service is starting and/or Dhcp service might not yet configured the DNS.

I presume changing the Endpoint= lines of peers to contain IPs rather than hostnames could solve your problem.

See if it helps.

If you can confirm it, maybe we can add some retry on WSANO_DATA in the wireguard-windows. (Personally, I would avoid adding hard dependency on Dnscache and Dhcp services. As there are situations where they can be disabled, preventing the WireGuard tunnel service startup then.) 

Regards,
Simon

From dev1 at tempforever.com  Wed Sep 28 16:34:49 2022
From: dev1 at tempforever.com (tempforever)
Date: Wed, 28 Sep 2022 12:34:49 -0400
Subject: APK outside of Play Store?
In-Reply-To: <517b5e80-d3ac-4829-9096-1415ecad5aa4@www.fastmail.com>
References: <517b5e80-d3ac-4829-9096-1415ecad5aa4@www.fastmail.com>
Message-ID: <286505c7-67b8-29dd-3cff-570851c3169c@tempforever.com>

wireguard at bulletin.elitemail.org wrote:
> For users who prefer to avoid Play Store as a delivery channel, is there an official pre-built APK available? Such users are typically steered towards APKPure/APKMirror/F-Droid with questionabl authenticity and (in the case of F-Droid) the prospect of old build dependencies built on an EOL OS (Strech). Aurora is an option, though a dev provided build (with accompanying checksum/signing cert fingerprint) would be preferable. 
>
It's on the wireguard installation/download page
https://www.wireguard.com/install/#android-play-store-f-droid

The f-droid link is https://f-droid.org/en/packages/com.wireguard.android/


From jeanphilippe.aumasson at gmail.com  Wed Sep 28 18:17:00 2022
From: jeanphilippe.aumasson at gmail.com (Jean-Philippe Aumasson)
Date: Wed, 28 Sep 2022 20:17:00 +0200
Subject: Iptables WireGuard obfuscation extension
In-Reply-To: <YzR3vcZhSjU2eRqB@zx2c4.com>
References: <183272e3203.12ada1173180167.8469340361616836666@zoho.com>
 <YzR3vcZhSjU2eRqB@zx2c4.com>
Message-ID: <CAGiyFdfYohSxNjXUyht88qNCfNtmy_MAm0NYn9Y-fj4RiJ9nyw@mail.gmail.com>

ChaCha6 is probably enough crypto-wise here.

On Wed 28 Sep 2022 at 18:35 Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hey Wei,
>
> On Sat, Sep 10, 2022 at 06:34:42AM -0500, Wei Chen wrote:
> > Hi,
> >
> > Jason once suggested use a netfilter module for obfuscation[1]. Here is
> one.
> >
> > https://github.com/infinet/xt_wgobfs
> >
> > It uses SipHash 1-2 to generate pseudo-random numbers in a reproducible
> way.
> > Sender and receiver share a siphash secret key. Sender creates and
> receiver
> > re-creates identical siphash output, if input is same. These siphash
> outputs
> > are used for obfuscation.
> >
> > - The first 16 bytes of WG message is obfuscated.
> > - The mac2 field is also obfuscated if it is all zeros.
> > - Padding WG message with random bytes, which also has random length.
> They are
> >   from kernel get_random_bytes_wait() though.
> > - Drop 80% of keepalive message at random. Again randomness is from
> kernel.
> > - Change the Diffserv field to zero.
> >
> > Tested working on Alpine linux kernel 5.15 and CentOS 7 kernel 3.10.
> >
> > Performance test in two Alpine VMs running on same host. Each VM has 1
> CPU and
> > 256 MB RAM. Iperf3 results 1.1Gbits/s without,vs 860Mbits/s with
> obfuscation.
>
> This is super cool! I'm very glad to see that you've made this.
>
> A couple considerations for improvement (take them or leave them):
>
> - Instead of using siphash, if you can make use of 64 bytes of
>   randomness at a time, you might be able to get away with chacha8 (or
>   even lower). The input to chacha20 is typically a 256 bit key and a
>   nonce, but because we don't care about the cryptographic security here
>   -- wireguard handles that part -- we can play fast and lose, and make
>   our threat model, "would be too computationally complex to detect in
>   real time". Things become quite fun when you don't need real crypto.
>   To that end, we could perhaps get away with using chacha8 instead of
>   chacha20, and doing so with a 128-bit key. This then provides lots of
>   input to chacha:
>
>   * 16 bytes, where the second half of that key was
>   * 16 bytes nonce (since it doesn't look like you need more than one
> block)
>   * If you really want to play fast and loose: 32-byte constant...
>
>   Again, this is awful cryptographic advice, but from a traffic analysis
>   point of view, I doubt it makes a difference.
>
>   On the other hand, if all you need is 16 bytes output, then I guess
>   siphash gets the job done.
>
> - get_random_bytes() is slow if all you need is a byte at a time. That
>   computes 96 bytes and then throws away 88 bytes of it. Instead, you
>   can use get_random_u32(), which batches, and throw away 3 bytes. Or, I
>   think I'll add to kernel 6.1 get_random_u8(), which will waste
>   nothing.
>
>   But actually, do you really need to do that? Can't you just run chacha
>   or siphash or whatever super fast non-cryptographic thing you have,
>   and just have an incrementing nonce? Or, better, since those keepalive
>   messages already have a suitably random poly1305 tag, just run siphash
>   on that, and discard if the resultant first byte is high/low/whatever.
>
> - If this is to ever go upstream, you might want to add a `--obfs-type
>   N` parameter to the XT userspace library and the IPC struct, and make
>   it mandatory. To begin, everybody would use `--obfs-type 1`, since
>   that's all there is. But maybe overtime, you'll add a fake TCP mode or
>   a fake QUIC mode or a fake HTML mode, and then the types will grow.
>   This way, maintenance wise, you only have to send updates to the
>   netfilter module in the kernel, and don't need to update the libxt
>   part.
>
> Jason
>

From david at bamsoftware.com  Wed Sep 28 19:23:08 2022
From: david at bamsoftware.com (David Fifield)
Date: Wed, 28 Sep 2022 13:23:08 -0600
Subject: Wireguard does not work in Iran
In-Reply-To: <561370843.2818033.1664357524603@mail.yahoo.com>
References: <561370843.2818033.1664357524603.ref@mail.yahoo.com>
 <561370843.2818033.1664357524603@mail.yahoo.com>
Message-ID: <20220928192308.cmr7vzbgp3bby2al@bamsoftware.com>

On Wed, Sep 28, 2022 at 09:32:04AM +0000, Mehdi Haghgoo wrote:
> It seems that Wireguard does not work at all in Iran.
> I used to use it with nmcli on Linux, but recently it just does not work, even with ADSL Internet (Mobile internet is mainly shut down).
> 
> I suspect it is not because UDP is completely blocked, because I see some other VPNs are working with UDP. Could the co
> 
> Are there any suggestions to make Wireguard work under recent harsh Internet crackdowns?

Some people are reporting success with two-hop proxies, since not all
networks in Iran are subject to the same blocking rules. The first hop
is to another host in Iran that is less censored; the second hop crosses
the border. I haven't seen a report of someone doing this with
onobfuscated WireGuard specifically, but it may work. The second link in
the list has a kcptun component, which is UDP.

tutorial for multi-hop shadowsocks servers
https://github.com/net4people/bbs/issues/126

Tutorial: setting up a Tor bridge for Iran
https://github.com/net4people/bbs/issues/127

Two-layered access
https://forum.torproject.net/t/two-layered-access/4783

In terms of obfuscation for the WireGuard protocol, here are some
references:

Iptables WireGuard obfuscation extension
https://lists.zx2c4.com/pipermail/wireguard/2022-September/007822.html

swgp-go (userspace obfuscation proxy)
https://lists.zx2c4.com/pipermail/wireguard/2022-June/007638.html

WireGuard with obfuscation support
https://lists.zx2c4.com/pipermail/wireguard/2021-September/007142.html
https://github.com/net4people/bbs/issues/88

WireGuard obfuscation using shadowsocks
https://lists.zx2c4.com/pipermail/wireguard/2019-January/003809.html

From houmie at gmail.com  Wed Sep 28 19:42:54 2022
From: houmie at gmail.com (Houman)
Date: Wed, 28 Sep 2022 20:42:54 +0100
Subject: Wireguard does not work in Iran
In-Reply-To: <20220928192308.cmr7vzbgp3bby2al@bamsoftware.com>
References: <561370843.2818033.1664357524603.ref@mail.yahoo.com>
 <561370843.2818033.1664357524603@mail.yahoo.com>
 <20220928192308.cmr7vzbgp3bby2al@bamsoftware.com>
Message-ID: <CABBZOsm+YVzZo_dL7AP0GhayLJWF-E8Jn3H=2Xh7d9sSpjsbgQ@mail.gmail.com>

David,

Thanks for sharing this. That's an impressive list of ways to connect
with Wireguard that I wasn't even aware of.

With the exception of shadowsocks, would the other obfuscations that
you listed here such as "Iptables extension'' or "swgp-go"  also work
with the Wireguard iOS library? As I understand it, both the server
and client have to support it.

Many Thanks,
Houman


On Wed, 28 Sept 2022 at 20:26, David Fifield <david at bamsoftware.com> wrote:
>
> On Wed, Sep 28, 2022 at 09:32:04AM +0000, Mehdi Haghgoo wrote:
> > It seems that Wireguard does not work at all in Iran.
> > I used to use it with nmcli on Linux, but recently it just does not work, even with ADSL Internet (Mobile internet is mainly shut down).
> >
> > I suspect it is not because UDP is completely blocked, because I see some other VPNs are working with UDP. Could the co
> >
> > Are there any suggestions to make Wireguard work under recent harsh Internet crackdowns?
>
> Some people are reporting success with two-hop proxies, since not all
> networks in Iran are subject to the same blocking rules. The first hop
> is to another host in Iran that is less censored; the second hop crosses
> the border. I haven't seen a report of someone doing this with
> onobfuscated WireGuard specifically, but it may work. The second link in
> the list has a kcptun component, which is UDP.
>
> tutorial for multi-hop shadowsocks servers
> https://github.com/net4people/bbs/issues/126
>
> Tutorial: setting up a Tor bridge for Iran
> https://github.com/net4people/bbs/issues/127
>
> Two-layered access
> https://forum.torproject.net/t/two-layered-access/4783
>
> In terms of obfuscation for the WireGuard protocol, here are some
> references:
>
> Iptables WireGuard obfuscation extension
> https://lists.zx2c4.com/pipermail/wireguard/2022-September/007822.html
>
> swgp-go (userspace obfuscation proxy)
> https://lists.zx2c4.com/pipermail/wireguard/2022-June/007638.html
>
> WireGuard with obfuscation support
> https://lists.zx2c4.com/pipermail/wireguard/2021-September/007142.html
> https://github.com/net4people/bbs/issues/88
>
> WireGuard obfuscation using shadowsocks
> https://lists.zx2c4.com/pipermail/wireguard/2019-January/003809.html

From jan.petrischkeit at hochschule-stralsund.de  Thu Sep 29 05:43:45 2022
From: jan.petrischkeit at hochschule-stralsund.de (Jan Petrischkeit)
Date: Thu, 29 Sep 2022 07:43:45 +0200
Subject: wireguard-windows: Wireguard does not start a previously
 activated tunnel from time to time
In-Reply-To: <03b8866a0f8249c8883d9a0244ddea1b@rozman.si>
References: <4e093a02-723d-22ff-fd33-f220ac24e19e@hochschule-stralsund.de>
 <03b8866a0f8249c8883d9a0244ddea1b@rozman.si>
Message-ID: <3a27c871-f150-44fe-6d29-d5191be6cf79@hochschule-stralsund.de>

Hi,

thank you for this information, I will take a look at that. Now I know 
where to look.

However, I am using the "endpoint-by-dns" for a specific reason:
In my area there is an internet provider which uses carrier grade nat in 
a strange way, so that no rdp session can be created over a wireguard 
tunnel if the ipv4 address of the server is used as endpoint. I created 
a dns entry for the wireguard server, so that in these cases the ipv6 
address is used and the tunnel is established without the weird nat of 
the internet provider in between.
Since not all people here have activated ipv6 in their home routers or 
have always an ipv6 connection while traveling, I cannot simply use the 
ipv6 adress in the config.

Regards,
Jan


Am 28.09.22 um 19:23 schrieb Simon Rozman:
> Hi,
> 
>> Event 7023, ServiceControlManager: The service "WireGuardTunnel$HOST-
>> WG2" was terminated with the following error: The requested name is valid,
>> but no data of the requested type was found.
> 
> The error message you are mentioning is WSANO_DATA 11004 which is related to DNS resolution problems. Which is kind of expected early in the boot process when the Dnscache service is starting and/or Dhcp service might not yet configured the DNS.
> 
> I presume changing the Endpoint= lines of peers to contain IPs rather than hostnames could solve your problem.
> 
> See if it helps.
> 
> If you can confirm it, maybe we can add some retry on WSANO_DATA in the wireguard-windows. (Personally, I would avoid adding hard dependency on Dnscache and Dhcp services. As there are situations where they can be disabled, preventing the WireGuard tunnel service startup then.)
> 
> Regards,
> Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5386 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20220929/578880be/attachment.p7s>

From evrim at core.gen.tr  Wed Sep 28 21:58:01 2022
From: evrim at core.gen.tr (Evrim Ulu)
Date: Thu, 29 Sep 2022 00:58:01 +0300
Subject: Wireguard does not work in Iran
In-Reply-To: <20220928192308.cmr7vzbgp3bby2al@bamsoftware.com>
References: <561370843.2818033.1664357524603.ref@mail.yahoo.com>
 <561370843.2818033.1664357524603@mail.yahoo.com>
 <20220928192308.cmr7vzbgp3bby2al@bamsoftware.com>
Message-ID: <87czbfyxcq.fsf@core.gen.tr>


Hi there.

Here is my old attempt, may help.

Description:
https://www.core.gen.tr/posts/008-fixing-wireguard/

Patch:
https://www.core.gen.tr/patches/wg-evrim-5.18.0.patch


best,
evrim.

David Fifield <david at bamsoftware.com> writes:

> On Wed, Sep 28, 2022 at 09:32:04AM +0000, Mehdi Haghgoo wrote:
>> It seems that Wireguard does not work at all in Iran.
>> I used to use it with nmcli on Linux, but recently it just does 
>> not work, even with ADSL Internet (Mobile internet is mainly 
>> shut down).
>> 
>> I suspect it is not because UDP is completely blocked, because 
>> I see some other VPNs are working with UDP. Could the co
>> 
>> Are there any suggestions to make Wireguard work under recent 
>> harsh Internet crackdowns?
>
> Some people are reporting success with two-hop proxies, since 
> not all
> networks in Iran are subject to the same blocking rules. The 
> first hop
> is to another host in Iran that is less censored; the second hop 
> crosses
> the border. I haven't seen a report of someone doing this with
> onobfuscated WireGuard specifically, but it may work. The second 
> link in
> the list has a kcptun component, which is UDP.
>
> tutorial for multi-hop shadowsocks servers
> https://github.com/net4people/bbs/issues/126
>
> Tutorial: setting up a Tor bridge for Iran
> https://github.com/net4people/bbs/issues/127
>
> Two-layered access
> https://forum.torproject.net/t/two-layered-access/4783
>
> In terms of obfuscation for the WireGuard protocol, here are 
> some
> references:
>
> Iptables WireGuard obfuscation extension
> https://lists.zx2c4.com/pipermail/wireguard/2022-September/007822.html
>
> swgp-go (userspace obfuscation proxy)
> https://lists.zx2c4.com/pipermail/wireguard/2022-June/007638.html
>
> WireGuard with obfuscation support
> https://lists.zx2c4.com/pipermail/wireguard/2021-September/007142.html
> https://github.com/net4people/bbs/issues/88
>
> WireGuard obfuscation using shadowsocks
> https://lists.zx2c4.com/pipermail/wireguard/2019-January/003809.html