From labawi-wg at matrix-dream.net Sun Sep 3 03:21:25 2023 From: labawi-wg at matrix-dream.net (Ivan =?iso-8859-1?Q?Lab=E1th?=) Date: Sun, 3 Sep 2023 03:21:25 +0000 Subject: [RFC] Replace WireGuard AllowedIPs with IP route attribute In-Reply-To: <20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at> References: <20230819140218.5algu2nfmfostngh@House.clients.dxld.at> <4b-64e11f80-13-5e880900@8744214> <20230819212357.lkshcpslkgbeaq4e@House.clients.dxld.at> <20230828160705.a5uxv5l2zknna7yj@House.clients.dxld.at> <87v8czqd3w.wl-jch@irif.fr> <20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at> Message-ID: Hi, IMO, a good tunnel solution may be if what is now called AllowedIPs, were functionally split into: - AcceptIPS (to be different from AllowedIPs) - RouteIPs Perhaps with a default shorthand of, say, IPs, setting both, as AllowedIPs historically caused confusion wrt. it's meaning. Wireguard API is a bit clunky, but I think one could dynamically manage routes in reasonably efficient ways without extra interfaces and layers. Not sure if it would fullfill all reasonably achievable goals. Don't really have the time to implement anything, and I'm sure it would not be easy, so just a possible tip to consider. Regards, Ivan Lab?th On Tue, Aug 29, 2023 at 12:13:12AM +0200, Daniel Gr?ber wrote: > Hi Juliusz, > > On Mon, Aug 28, 2023 at 07:40:51PM +0200, Juliusz Chroboczek wrote: > > I've read the whole discussion, and I'm still not clear what advantages > > the proposed route attribute has over having one interface per peer. Is > > it because interfaces are expensive in the Linux kernel? Or is there some > > other reason why it is better to run all WG tunnels over a single interface? > > Off the top of my head UDP port exhaustion is a scalability concern here, > just as an example, not that I'd actually ever need that many peers in my > network :) > > One wg-device per-peer means we need one UDP port per-peer and since > currently binding to a specific IP is also not supported by wg (I have a > patch pending for this though) there's no good way to work around this. > > Frankly having tons of interfaces is just an operational PITA in all sorts > of ways. Apart from the port exhaustion having more than one wg device also > means I have to _allocate_ a new port for each node in my managment system > somehow instead of just using a static port for the entire network. This > gets dicy fast as I want to move in the direction of dynamic peering as in > tinc. > > Other than that my `ip -br a` output is getting unmanagably long and having > more than one device means I have to keep ACL lists in sync all over the > system. This is a problem for daemons that don't support automatic reload > (babeld for example :P). I also have to sync the set of interface to > nftables which is easy to get wrong as it's still manual in my setup. > > All of that could be solved, but I would also like to get my wg+babel VPN > setup deployed more widely at some point and all that friction isn't going > to help with that so I'd rather have this supported properly. > > --Daniel From jp at sec.uni-passau.de Thu Sep 28 09:56:17 2023 From: jp at sec.uni-passau.de (Posegga, Joachim) Date: Thu, 28 Sep 2023 09:56:17 +0000 Subject: MAC OS 14 / Sonoma Message-ID: Hi, I cannot route traffic through established WG tunnels after upgrading to macOS 14.0 Sonoma (23A344). Anyone having similar issues? Joachim. From jp at sec.uni-passau.de Thu Sep 28 14:24:07 2023 From: jp at sec.uni-passau.de (Posegga, Joachim) Date: Thu, 28 Sep 2023 14:24:07 +0000 Subject: MAC OS 14 / Sonoma In-Reply-To: References: Message-ID: .... sorry, this was false alarm: The culprit was the conference WLAN in The Hague that WAS blocking WG-traffic. I did not expect such packet filtering in the Netherlands. - Joachim. ?On 28.09.23, 11:56, "Posegga, Joachim" > wrote: Hi, I cannot route traffic through established WG tunnels after upgrading to macOS 14.0 Sonoma (23A344). Anyone having similar issues? Joachim. From dxld at darkboxed.org Fri Sep 29 13:12:57 2023 From: dxld at darkboxed.org (Daniel =?utf-8?Q?Gr=C3=B6ber?=) Date: Fri, 29 Sep 2023 15:12:57 +0200 Subject: [RFC] Replace WireGuard AllowedIPs with IP route attribute In-Reply-To: Message-ID: <20230929131257.4uyp3fkxkxt7qg3f@darkboxed.org> Hi Ivan, > IMO, a good tunnel solution may be if what is now called AllowedIPs, > were functionally split into: > - AcceptIPS (to be different from AllowedIPs) > - RouteIPs > Perhaps with a default shorthand of, say, IPs, setting both, as > AllowedIPs historically caused confusion wrt. it's meaning. That would be one way to paint the shed, yes. This alone doesn't really address the crux of the problem though: scalability. > Wireguard API is a bit clunky, but I think one could dynamically manage > routes in reasonably efficient ways without extra interfaces and layers. The entire idea with the new route attribute is to put this functionality into the right (pre-existing) layer and not invent a new way of expressing this. We even get scalability for free. Win-Win. --Daniel PS: Your mail didn't reach my inbox for some reason, I randomly found it while looking at the wg list archives. Consider configuring your mail client to To/CC people you're replying to in order to better handle flaky list servers. From syzbot+c1cc0083f159b67cb192 at syzkaller.appspotmail.com Fri Sep 29 19:45:19 2023 From: syzbot+c1cc0083f159b67cb192 at syzkaller.appspotmail.com (syzbot) Date: Fri, 29 Sep 2023 12:45:19 -0700 Subject: [syzbot] [wireguard?] INFO: rcu detected stall in wg_ratelimiter_gc_entries (2) In-Reply-To: <00000000000021dc2806031ad901@google.com> Message-ID: <0000000000001be691060684aa2c@google.com> syzbot suspects this issue was fixed by commit: commit da71714e359b64bd7aab3bd56ec53f307f058133 Author: Jamal Hadi Salim Date: Tue Aug 22 10:12:31 2023 +0000 net/sched: fix a qdisc modification with ambiguous command request bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=129c464e680000 start commit: 8a519a572598 net: veth: Page pool creation error handling .. git tree: net kernel config: https://syzkaller.appspot.com/x/.config?x=3e670757e16affb dashboard link: https://syzkaller.appspot.com/bug?extid=c1cc0083f159b67cb192 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=129f8553a80000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1205baada80000 If the result looks correct, please mark the issue as fixed by replying with: #syz fix: net/sched: fix a qdisc modification with ambiguous command request For information about bisection process see: https://goo.gl/tpsmEJ#bisection From houmie at gmail.com Sat Sep 30 19:09:06 2023 From: houmie at gmail.com (Houman) Date: Sat, 30 Sep 2023 20:09:06 +0100 Subject: =?UTF-8?Q?Wireguard=2Dapple_1=2E0=2E16=2D27_can=E2=80=99t_be_added_via_SPM?= Message-ID: Hello Jason, Andrej Please try to add the latest Wireguard-Apple 1.0.16-27 via Swift Package Manager and you will see that fails. The issue could be related to swift-tools-version. Please advise what to do? Thank you. Houman From v at sess.ink Tue Sep 5 14:04:35 2023 From: v at sess.ink (Valentijn Sessink) Date: Tue, 05 Sep 2023 14:04:35 -0000 Subject: AllowedIPs = ::/0 routes IPv4 - on Android? Message-ID: <63bb2149-2d0b-df64-27f9-6e003dfdc577@openoffice.nl> Hi List, I have a WG endpoint configured with AllowedIPs = ::/0 ... on an Android phone. To my surprise, I found out that this also tries to route IPv4 addresses to the other WG side. I was able to change that with a single "bogus" IPv4 address, "AllowedIPs = ::/0, 192.0.2.99/32" Is this a known feature? Android 13, WireGuard for Android v1.0.20230707, (from AOSP). Best regards, Valentijn From info at euro-domenii.eu Tue Sep 19 13:13:53 2023 From: info at euro-domenii.eu (EuroDomenii .Eu .Ro Accredited Registrar) Date: Tue, 19 Sep 2023 13:13:53 -0000 Subject: WireGuard as Android Device Owner Message-ID: Dear all, I'm tryin to set up WireGuard as Android Device Owner, but it fails, even though there's the very same code that worked with Shadowsocks fork. Below the files samples and full error message. Thanks! *ui/src/main/AndroidManifest.xml
*ui/src/main/java/com/wireguard/android/WireGuardReceiver.kt 
/*
 * Copyright ? 2017-2023 WireGuard LLC. All Rights Reserved.
 * SPDX-License-Identifier: Apache-2.0
 */

package com.wireguard.android

import android.app.admin.DeviceAdminReceiver

/**
 * Trivial DeviceAdminReceiver used to identify this app's device administrator.
 */
class WireGuardReceiver : DeviceAdminReceiver()
ui/src/main/res/xml/device_owner_receiver.xml
*Error 
root at androids ~/AndroidStudioProjects/wireguard-android # adb shell
emu64x:/ $ dpm set-device-owner com.wireguard.android/.WireGuardReceiver

Exception occurred while executing 'set-device-owner':
java.lang.IllegalArgumentException: Unknown admin:
ComponentInfo{com.wireguard.android/com.wireguard.android.WireGuardReceiver}
        at com.android.server.devicepolicy.DevicePolicyManagerService.findAdmin(DevicePolicyManagerService.java:2838)
        at com.android.server.devicepolicy.DevicePolicyManagerService.setActiveAdmin(DevicePolicyManagerService.java:3342)
        at com.android.server.devicepolicy.DevicePolicyManagerServiceShellCommand.runSetDeviceOwner(DevicePolicyManagerServiceShellCommand.java:256)
        at com.android.server.devicepolicy.DevicePolicyManagerServiceShellCommand.onCommand(DevicePolicyManagerServiceShellCommand.java:89)
        at com.android.modules.utils.BasicShellCommandHandler.exec(BasicShellCommandHandler.java:97)
        at android.os.ShellCommand.exec(ShellCommand.java:38)
        at com.android.server.devicepolicy.DevicePolicyManagerService.onShellCommand(DevicePolicyManagerService.java:9905)
        at android.os.Binder.shellCommand(Binder.java:1049)
        at android.os.Binder.onTransact(Binder.java:877)
        at android.app.admin.IDevicePolicyManager$Stub.onTransact(IDevicePolicyManager.java:6054)
        at android.os.Binder.execTransactInternal(Binder.java:1285)
        at android.os.Binder.execTransact(Binder.java:1244)
From otilibil at eurecom.fr Thu Sep 21 13:40:22 2023 From: otilibil at eurecom.fr (Ariel Otilibili Anieli) Date: Thu, 21 Sep 2023 13:40:22 -0000 Subject: [PATCH 1/1] .DEFAULT_GOAL is a variable, not a target Message-ID: <20230921154021.vy0q428740gggsos@webmail.eurecom.fr> Makefile has been working because, in the script, `wg` appears as first target. https://www.gnu.org/software/make/manual/html_node/Special-Variables.html Signed-off-by: Ariel Otilibili --- src/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/Makefile b/src/Makefile index 0533910..9f450e7 100644 --- a/src/Makefile +++ b/src/Makefile @@ -108,7 +108,7 @@ check: clean scan-build --html-title=wireguard-tools -maxloop 100 --view --keep-going $(MAKE) wg all: wg -.DEFAULT_GOAL: all +.DEFAULT_GOAL := all .PHONY: clean install check -include *.d -- 2.42.0 ------------------------------------------------------------------------------- This message was sent using EURECOM Webmail: http://webmail.eurecom.fr From venkata at instasafe.com Thu Sep 28 10:36:41 2023 From: venkata at instasafe.com (Venkatakrishna S) Date: Thu, 28 Sep 2023 10:36:41 -0000 Subject: MAC OS 14 / Sonoma In-Reply-To: References: Message-ID: Hey, Not facing issues with VPN , but have some macOS service related issues for VPN. The service handles VPN for me. Thanks & RegardsVenkatakrishna S On Thu, Sep 28, 2023 at 4:05?PM Venkatakrishna S wrote: > > Hey, > > Not facing issues with VPN , but have some macOS service related issues for VPN. The service handles VPN for me. > > Thanks & Regards > Venkatakrishna S > > On Thu, Sep 28, 2023 at 3:28?PM Posegga, Joachim wrote: >> >> Hi, >> >> I cannot route traffic through established WG tunnels after upgrading to macOS 14.0 Sonoma (23A344). Anyone having similar issues? >> >> Joachim. >> From reto at slightlybroken.com Fri Sep 29 16:19:18 2023 From: reto at slightlybroken.com (Reto) Date: Fri, 29 Sep 2023 16:19:18 -0000 Subject: [RFC] Replace WireGuard AllowedIPs with IP route attribute In-Reply-To: <20230929131257.4uyp3fkxkxt7qg3f@darkboxed.org> References: <20230929131257.4uyp3fkxkxt7qg3f@darkboxed.org> Message-ID: On Fri, Sep 29, 2023 at 03:12:57PM +0200, Daniel Gr?ber wrote: > PS: Your mail didn't reach my inbox for some reason, I randomly found it > while looking at the wg list archives. Consider configuring your mail > client to To/CC people you're replying to in order to better handle flaky > list servers. Well... Date: Sun, 3 Sep 2023 03:21:25 +0000 From: Ivan Lab?th To: Daniel Gr?ber Cc: Juliusz Chroboczek , Kyle Rose , bird-users at network.cz, babel-users at alioth-lists.debian.net, wireguard at lists.zx2c4.com Subject: Re: [RFC] Replace WireGuard AllowedIPs with IP route attribute Message-ID: They did. Cheers, Reto