From peljasz at yahoo.co.uk Sat Apr 2 17:41:12 2022 From: peljasz at yahoo.co.uk (lejeczek) Date: Sat, 2 Apr 2022 18:41:12 +0100 Subject: MTUs go strange ways - ? References: Message-ID: Hi guys I thought there was no better place to ask but here so - both ends are centOS and end up having different MTUs for 'wg' interfaces and that I thought, was wrong. 1370 (server) VS 1320 (client) I expected that would be negotiated between nodes without user involved, right? Moreover if I from the client do: -> $ ping server -M do -s 1300 PING 10.3.3.1 (10.3.3.1) 1300(1328) bytes of data. ping: local error: message too long, mtu=1320 Could some expert or two shed more light on what & why is happening? many thanks, L. From nomad at null.net Sun Apr 3 20:14:59 2022 From: nomad at null.net (Mark Lawrence) Date: Sun, 3 Apr 2022 22:14:59 +0200 Subject: MTUs go strange ways - ? In-Reply-To: References: Message-ID: On Sat Apr 02, 2022 at 06:41:12PM +0100, lejeczek wrote: >1370 (server) VS 1320 (client) > >Could some expert or two shed more light on what & why is happening? There is a (very small) clue in the name: Maximum *Transmission* Unit. Routing between two IP addresses is not (necessarily) symetric: routes are computed independently in each direction. So there is probably a (1320 MTU) device somewhere inbetween which is only crossed by packets in the client->server direction, but not in the reverse. -- Mark Lawrence From frank at deze.org Mon Apr 4 06:55:58 2022 From: frank at deze.org (Frank Volf) Date: Mon, 4 Apr 2022 08:55:58 +0200 Subject: MTUs go strange ways - ? In-Reply-To: References: Message-ID: <88efb74e-39ec-99e5-98a8-244e0af70724@deze.org> Hi, The "-s" option provides the length of the ICMP data in the packet, not the total packet length. To the data size you need to add 8 bytes for the ICMP header and 20 bytes for the IP header. So, you are sending 1328 bytes (which is noted between the brackets in your output). If you change to "-s 1292" then you are actually sending packets with total length of 1320. Kind regards, Frank Op 2-4-2022 om 19:41 schreef lejeczek: > Hi guys > > I thought there was no better place to ask but here so - both ends are > centOS and end up having different MTUs for 'wg' interfaces and that I > thought, was wrong. > 1370 (server) VS 1320 (client) > I expected that would be negotiated between nodes without user > involved, right? > Moreover if I from the client do: > > -> $ ping server -M do -s 1300 > PING 10.3.3.1 (10.3.3.1) 1300(1328) bytes of data. > ping: local error: message too long, mtu=1320 > > Could some expert or two shed more light on what & why is happening? > many thanks, L. > From s.devanath at gmail.com Mon Apr 4 21:34:52 2022 From: s.devanath at gmail.com (Devanath S) Date: Mon, 4 Apr 2022 14:34:52 -0700 Subject: wireguard performance Message-ID: Hi All, We were trying to test the performance of wireguard on GCP and found it around 1G for TCP and around 500-800 for UDP. Plz do let us know if there are any ways to UP this performance. Any suggestion is appreciated. Regards Dev From joe at solidadmin.com Mon Apr 4 22:56:24 2022 From: joe at solidadmin.com (Joe Doss) Date: Mon, 4 Apr 2022 17:56:24 -0500 Subject: wireguard performance In-Reply-To: References: Message-ID: <22f7069e-fac3-09e8-5f2e-2d3c93506352@solidadmin.com> On 4/4/22 4:34 PM, Devanath S wrote: > We were trying to test the performance of wireguard on GCP and found > it around 1G for TCP and around 500-800 for UDP. > > Plz do let us know if there are any ways to UP this performance. Any > suggestion is appreciated. GCP network defaults to a lower MTU (1460). You might want to adjust your WireGuard tunnel's MTUs and the default GCP VPC MTU. See: https://cloud.google.com/network-connectivity/docs/vpn/concepts/mtu-considerations Joe -- Joe Doss joe at solidadmin.com From jhb at FreeBSD.org Tue Apr 5 22:46:42 2022 From: jhb at FreeBSD.org (John Baldwin) Date: Tue, 5 Apr 2022 15:46:42 -0700 Subject: Patches against wireguard-freebsd Message-ID: <5bf5dd1f-8e21-ece2-ef3c-f62e752cb774@FreeBSD.org> I have a series of patches against the FreeBSD driver available on the jb-wip branch which I believe is (mostly) a candidate for merging to master. The changes in the branch include: - 9d1881a Only include compat.h for if_wg.c and fix build with an obj directory. This patch permits building the module as part of a kernel build via the LOCAL_MODULES hook in 'make buildkernel'. - 2c4b941 wg_queue_len: Remove locking. - 61b401e wg_queue_delist_staged: Use more standard STAILQ_CONCAT. Misc small fixes, generally cosmetic. - d746eed wgc_get/set: Use M_WAITOK with malloc(). - 9223fbb wg_clone_create: Use M_WAITOK with malloc. - 9095ebe wg_peer_alloc and wg_aip_add: Use M_WAITOK with malloc. The ioctl path in FreeBSD generally uses M_WAITOK rather than M_NOWAIT (e.g. the non-smalldata case in sys_ioctl()). This slightly simplifies the code by avoiding additional edge cases to handle. It is also true that FreeBSD admins do not generally expect 'ifconfig create' to fail non-deterministically (that is, they only expect failure for things like invalid arguments, missing kernel module, etc.). - 4fbba97 wg_mbuf_reset: Don't free send tags. - 0a5fa77 ratelimit_init: Use callout_init_mtx. More misc small fixes. - a679db5 DNM: Add counters for the times en/decrypt tasks do no work. This is the one commit that I don't think is a merge candidate, instead it adds some counters useful for evaluating the effect of the next commit. - 89f91dc Avoid scheduling excessive tasks for encryption/decryption. There is more detail in the commit log, but this commit changes the scheduling of encryption/decryption tasks to match the behavior of the WireGuard driver in Linux instead of the current approach of scheduling a task on all available CPUs for every packet. In my performance benchmarks of this series, this commit had the single largest effect of any of the changes. My benchmark consisted of running iperf across a tunnel between two jails on the same host (an X1 Carbon laptop with 8 CPU threads). This commit generally resulted in a doubling of throughput for both UDP and TCP with 1, 2, 4, or 8 streams. To better explain why this change matters, I sampled the counters added in the previous commit for a sample run of iperf with a single TCP stream. The "empty" counters count the number of tasks which ran on a CPU but had no work to do, the "work" counters count the number of tasks which encrypted or decrypted at least one packet. Using the current code gave the following counts: hw.wg.encrypt_work: 992858 hw.wg.encrypt_empty: 6274830 hw.wg.decrypt_work: 1114235 hw.wg.decrypt_empty: 7064707 encrypt efficiency: 13.7% decrypt efficiency: 13.6% The efficiency is close to the 12.5% worst-case for an 8 CPU system. Using the code in this commit gave the following: hw.wg.encrypt_work: 1486616 hw.wg.encrypt_empty: 783377 hw.wg.decrypt_work: 1880567 hw.wg.decrypt_empty: 657807 encrypt efficiency: 65.5% decrypt efficiency: 74.1% Note: The increased "work" counts here are a result of the increased throughput In addition, a user recently mailed Jason and I directly to say that this commit greatly reduced the power usage for a WG endpoint in an ESXi VM putting the FreeBSD VM nearly on par with a Linux VM performing the same work. - 4e0478f wg_module_init: Clean up more if the self tests fail. - b885223 Return an error code from mbuf crypt routines. Small fixes preparing to use crypto support from FreeBSD. - ce85779 Use OCF to encrpyt/decrypt packets when supported. - 8ad55a8 Use when present. - 447abb Use curve25519 API from the kernel when available. Use crypto support from FreeBSD's kernel on new-enough versions (the OCF bits are available on 13.0-stable and later, the rest are only present in 14.0-current). FreeBSD's kernel does not currently provide a suitable API for Blake2 that matches WireGuard's needs, but does provide suitable APIs for the other crypto algorithms used by WireGuard in 14.0-current. -- John Baldwin From kevans at freebsd.org Fri Apr 8 18:40:36 2022 From: kevans at freebsd.org (Kyle Evans) Date: Fri, 8 Apr 2022 13:40:36 -0500 Subject: Patches against wireguard-freebsd In-Reply-To: <5bf5dd1f-8e21-ece2-ef3c-f62e752cb774@FreeBSD.org> References: <5bf5dd1f-8e21-ece2-ef3c-f62e752cb774@FreeBSD.org> Message-ID: On Tue, Apr 5, 2022 at 5:49 PM John Baldwin wrote: > > I have a series of patches against the FreeBSD driver available on > the jb-wip branch which I believe is (mostly) a candidate for merging > to master. The changes in the branch include: > > - 9d1881a Only include compat.h for if_wg.c and fix build with an obj directory. > > This patch permits building the module as part of a kernel build via > the LOCAL_MODULES hook in 'make buildkernel'. > LGTM. > - 2c4b941 wg_queue_len: Remove locking. > - 61b401e wg_queue_delist_staged: Use more standard STAILQ_CONCAT. > > Misc small fixes, generally cosmetic. > I wanted to argue against 2c4b941, but it occurred to me that since the caller's not holding the lock we don't have any guarantees about the state of the queue by the time we use the result anyways. LGTM. > - d746eed wgc_get/set: Use M_WAITOK with malloc(). > - 9223fbb wg_clone_create: Use M_WAITOK with malloc. > - 9095ebe wg_peer_alloc and wg_aip_add: Use M_WAITOK with malloc. > > The ioctl path in FreeBSD generally uses M_WAITOK rather than M_NOWAIT > (e.g. the non-smalldata case in sys_ioctl()). This slightly simplifies > the code by avoiding additional edge cases to handle. It is also true > that FreeBSD admins do not generally expect 'ifconfig create' to fail > non-deterministically (that is, they only expect failure for things > like invalid arguments, missing kernel module, etc.). > LGTM. > - 4fbba97 wg_mbuf_reset: Don't free send tags. > - 0a5fa77 ratelimit_init: Use callout_init_mtx. > > More misc small fixes. LGTM. > > - a679db5 DNM: Add counters for the times en/decrypt tasks do no work. > > This is the one commit that I don't think is a merge candidate, instead > it adds some counters useful for evaluating the effect of the next > commit. > > - 89f91dc Avoid scheduling excessive tasks for encryption/decryption. > > There is more detail in the commit log, but this commit changes the > scheduling of encryption/decryption tasks to match the behavior of the > WireGuard driver in Linux instead of the current approach of > scheduling a task on all available CPUs for every packet. In my > performance benchmarks of this series, this commit had the single > largest effect of any of the changes. My benchmark consisted of > running iperf across a tunnel between two jails on the same host (an > X1 Carbon laptop with 8 CPU threads). This commit generally resulted > in a doubling of throughput for both UDP and TCP with 1, 2, 4, or 8 > streams. > > To better explain why this change matters, I sampled the counters > added in the previous commit for a sample run of iperf with a single > TCP stream. The "empty" counters count the number of tasks which ran > on a CPU but had no work to do, the "work" counters count the number > of tasks which encrypted or decrypted at least one packet. > > Using the current code gave the following counts: > > hw.wg.encrypt_work: 992858 > hw.wg.encrypt_empty: 6274830 > hw.wg.decrypt_work: 1114235 > hw.wg.decrypt_empty: 7064707 > > encrypt efficiency: 13.7% > decrypt efficiency: 13.6% > > The efficiency is close to the 12.5% worst-case for an 8 CPU system. > > Using the code in this commit gave the following: > > hw.wg.encrypt_work: 1486616 > hw.wg.encrypt_empty: 783377 > hw.wg.decrypt_work: 1880567 > hw.wg.decrypt_empty: 657807 > > encrypt efficiency: 65.5% > decrypt efficiency: 74.1% > > Note: The increased "work" counts here are a result of the increased > throughput > > In addition, a user recently mailed Jason and I directly to say that > this commit greatly reduced the power usage for a WG endpoint in an > ESXi VM putting the FreeBSD VM nearly on par with a Linux VM > performing the same work. > Nice! LGTM > - 4e0478f wg_module_init: Clean up more if the self tests fail. > - b885223 Return an error code from mbuf crypt routines. > > Small fixes preparing to use crypto support from FreeBSD. > LGTM. > - ce85779 Use OCF to encrpyt/decrypt packets when supported. > - 8ad55a8 Use when present. > - 447abb Use curve25519 API from the kernel when available. > > Use crypto support from FreeBSD's kernel on new-enough versions (the > OCF bits are available on 13.0-stable and later, the rest are only > present in 14.0-current). FreeBSD's kernel does not currently provide > a suitable API for Blake2 that matches WireGuard's needs, but does > provide suitable APIs for the other crypto algorithms used by > WireGuard in 14.0-current. > Seems to LGTM. Thanks! Kyle Evans From linus at lotz.li Sun Apr 10 19:06:34 2022 From: linus at lotz.li (Linus Karl) Date: Sun, 10 Apr 2022 21:06:34 +0200 Subject: wireguard: add netlink mcast on endpoint change Message-ID: <20220410190635.1171195-1-linus@lotz.li> This patch adds the possibility to retrieve notifications of peer endpoint changes via netlink multicast messages. It has been a while since I posted v2, the main difference is that I've added an extra attribute to the netlink device attributes to allow enabling or disabling of this feature. It is per default disabled. From linus at lotz.li Sun Apr 10 19:06:35 2022 From: linus at lotz.li (Linus Karl) Date: Sun, 10 Apr 2022 21:06:35 +0200 Subject: [PATCH v3] wireguard: add netlink mcast on endpoint change In-Reply-To: <20220410190635.1171195-1-linus@lotz.li> References: <20220410190635.1171195-1-linus@lotz.li> Message-ID: <20220410190635.1171195-2-linus@lotz.li> This commit adds a new multicast group "peers" to the netlink api for wireguard. The purpose of this multicast group is to notify userspace when the peers of an interface change. This is also triggered when root changes the endpoint manually. This feature is enabled through setting a new WGDEVICE_A_MONITOR attribute to WGDEVICE_MONITOR_F_ENDPOINT. An example for an consumer of this API would be a service that keeps track of all peer endpoints and sends this information to the peers. This would allow NAT-to-NAT connections without the need of using STUN on each client. Signed-off-by: Linus Karl --- drivers/net/wireguard/device.h | 1 + drivers/net/wireguard/netlink.c | 68 +++++++++++++++++++++++++++++++-- drivers/net/wireguard/netlink.h | 4 ++ drivers/net/wireguard/socket.c | 5 +++ include/uapi/linux/wireguard.h | 12 ++++++ 5 files changed, 87 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireguard/device.h b/drivers/net/wireguard/device.h index 43c7cebbf50b..74d9d772cc94 100644 --- a/drivers/net/wireguard/device.h +++ b/drivers/net/wireguard/device.h @@ -54,6 +54,7 @@ struct wg_device { unsigned int num_peers, device_update_gen; u32 fwmark; u16 incoming_port; + bool endpoint_monitor; }; int wg_device_init(void); diff --git a/drivers/net/wireguard/netlink.c b/drivers/net/wireguard/netlink.c index d0f3b6d7f408..5902910e015e 100644 --- a/drivers/net/wireguard/netlink.c +++ b/drivers/net/wireguard/netlink.c @@ -27,7 +27,8 @@ static const struct nla_policy device_policy[WGDEVICE_A_MAX + 1] = { [WGDEVICE_A_FLAGS] = { .type = NLA_U32 }, [WGDEVICE_A_LISTEN_PORT] = { .type = NLA_U16 }, [WGDEVICE_A_FWMARK] = { .type = NLA_U32 }, - [WGDEVICE_A_PEERS] = { .type = NLA_NESTED } + [WGDEVICE_A_PEERS] = { .type = NLA_NESTED }, + [WGDEVICE_A_MONITOR] = { .type = NLA_U8 } }; static const struct nla_policy peer_policy[WGPEER_A_MAX + 1] = { @@ -233,7 +234,9 @@ static int wg_get_device_dump(struct sk_buff *skb, struct netlink_callback *cb) wg->incoming_port) || nla_put_u32(skb, WGDEVICE_A_FWMARK, wg->fwmark) || nla_put_u32(skb, WGDEVICE_A_IFINDEX, wg->dev->ifindex) || - nla_put_string(skb, WGDEVICE_A_IFNAME, wg->dev->name)) + nla_put_string(skb, WGDEVICE_A_IFNAME, wg->dev->name) || + nla_put_u8(skb, WGDEVICE_A_MONITOR, + wg->endpoint_monitor ? WGDEVICE_MONITOR_F_ENDPOINT : 0)) goto out; down_read(&wg->static_identity.lock); @@ -538,6 +541,15 @@ static int wg_set_device(struct sk_buff *skb, struct genl_info *info) goto out; } + if (info->attrs[WGDEVICE_A_MONITOR]) { + u8 monitor = nla_get_u8(info->attrs[WGDEVICE_A_MONITOR]); + + if (monitor & ~__WGDEVICE_MONITOR_F_ALL) + goto out; + wg->endpoint_monitor = + (monitor & WGDEVICE_MONITOR_F_ENDPOINT) == WGDEVICE_MONITOR_F_ENDPOINT; + } + if (flags & WGDEVICE_F_REPLACE_PEERS) wg_peer_remove_all(wg); @@ -618,6 +630,12 @@ static const struct genl_ops genl_ops[] = { } }; +static const struct genl_multicast_group wg_genl_mcgrps[] = { + { + .name = WG_MULTICAST_GROUP_PEERS + } +}; + static struct genl_family genl_family __ro_after_init = { .ops = genl_ops, .n_ops = ARRAY_SIZE(genl_ops), @@ -626,7 +644,9 @@ static struct genl_family genl_family __ro_after_init = { .maxattr = WGDEVICE_A_MAX, .module = THIS_MODULE, .policy = device_policy, - .netnsok = true + .netnsok = true, + .mcgrps = wg_genl_mcgrps, + .n_mcgrps = ARRAY_SIZE(wg_genl_mcgrps) }; int __init wg_genetlink_init(void) @@ -638,3 +658,45 @@ void __exit wg_genetlink_uninit(void) { genl_unregister_family(&genl_family); } + +int wg_genl_mcast_peer_endpoint_change(struct wg_peer *peer) +{ + struct sk_buff *skb; + void *hdr, *peer_nest, *peer_array_nest; + int fail = 0; + + skb = genlmsg_new(NLMSG_GOODSIZE, GFP_KERNEL); + hdr = genlmsg_put(skb, 0, 0, + &genl_family, 0, WG_CMD_CHANGED_PEER); + + nla_put_u32(skb, WGDEVICE_A_IFINDEX, peer->device->dev->ifindex); + nla_put_string(skb, WGDEVICE_A_IFNAME, peer->device->dev->name); + + peer_nest = nla_nest_start(skb, WGDEVICE_A_PEERS); + peer_array_nest = nla_nest_start(skb, 0); + down_read(&peer->handshake.lock); + nla_put(skb, WGPEER_A_PUBLIC_KEY, NOISE_PUBLIC_KEY_LEN, + peer->handshake.remote_static); + up_read(&peer->handshake.lock); + + read_lock_bh(&peer->endpoint_lock); + if (peer->endpoint.addr.sa_family == AF_INET) + fail = nla_put(skb, WGPEER_A_ENDPOINT, + sizeof(peer->endpoint.addr4), + &peer->endpoint.addr4); + else if (peer->endpoint.addr.sa_family == AF_INET6) + fail = nla_put(skb, WGPEER_A_ENDPOINT, + sizeof(peer->endpoint.addr6), + &peer->endpoint.addr6); + read_unlock_bh(&peer->endpoint_lock); + if (fail) + return fail; + + nla_nest_end(skb, peer_array_nest); + nla_nest_end(skb, peer_nest); + genlmsg_end(skb, hdr); + + fail = genlmsg_multicast_netns(&genl_family, dev_net(peer->device->dev), + skb, 0, 0, GFP_KERNEL); + return fail; +} diff --git a/drivers/net/wireguard/netlink.h b/drivers/net/wireguard/netlink.h index 15100d92e2e3..74ecc72a79a6 100644 --- a/drivers/net/wireguard/netlink.h +++ b/drivers/net/wireguard/netlink.h @@ -6,6 +6,10 @@ #ifndef _WG_NETLINK_H #define _WG_NETLINK_H +#include "peer.h" + +int wg_genl_mcast_peer_endpoint_change(struct wg_peer *peer); + int wg_genetlink_init(void); void wg_genetlink_uninit(void); diff --git a/drivers/net/wireguard/socket.c b/drivers/net/wireguard/socket.c index 0414d7a6ce74..33e4da2a37ee 100644 --- a/drivers/net/wireguard/socket.c +++ b/drivers/net/wireguard/socket.c @@ -8,6 +8,7 @@ #include "socket.h" #include "queueing.h" #include "messages.h" +#include "netlink.h" #include #include @@ -294,6 +295,10 @@ void wg_socket_set_peer_endpoint(struct wg_peer *peer, dst_cache_reset(&peer->endpoint_cache); out: write_unlock_bh(&peer->endpoint_lock); + + if (peer->device->endpoint_monitor) { + wg_genl_mcast_peer_endpoint_change(peer); + } } void wg_socket_set_peer_endpoint_from_skb(struct wg_peer *peer, diff --git a/include/uapi/linux/wireguard.h b/include/uapi/linux/wireguard.h index ae88be14c947..cde044fb1124 100644 --- a/include/uapi/linux/wireguard.h +++ b/include/uapi/linux/wireguard.h @@ -29,6 +29,7 @@ * WGDEVICE_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN * WGDEVICE_A_LISTEN_PORT: NLA_U16 * WGDEVICE_A_FWMARK: NLA_U32 + * WGDEVICE_A_MONITOR: NLA_U8 * WGDEVICE_A_PEERS: NLA_NESTED * 0: NLA_NESTED * WGPEER_A_PUBLIC_KEY: NLA_EXACT_LEN, len WG_KEY_LEN @@ -83,6 +84,9 @@ * WGDEVICE_A_PRIVATE_KEY: len WG_KEY_LEN, all zeros to remove * WGDEVICE_A_LISTEN_PORT: NLA_U16, 0 to choose randomly * WGDEVICE_A_FWMARK: NLA_U32, 0 to disable + * WGDEVICE_A_MONITOR: NLA_U8, set to a value of wgdevice_monitor_flag to + * enable monitoring of events using multicast messages + * over netlink * WGDEVICE_A_PEERS: NLA_NESTED * 0: NLA_NESTED * WGPEER_A_PUBLIC_KEY: len WG_KEY_LEN @@ -136,9 +140,12 @@ #define WG_KEY_LEN 32 +#define WG_MULTICAST_GROUP_PEERS "peers" + enum wg_cmd { WG_CMD_GET_DEVICE, WG_CMD_SET_DEVICE, + WG_CMD_CHANGED_PEER, __WG_CMD_MAX }; #define WG_CMD_MAX (__WG_CMD_MAX - 1) @@ -157,9 +164,14 @@ enum wgdevice_attribute { WGDEVICE_A_LISTEN_PORT, WGDEVICE_A_FWMARK, WGDEVICE_A_PEERS, + WGDEVICE_A_MONITOR, __WGDEVICE_A_LAST }; #define WGDEVICE_A_MAX (__WGDEVICE_A_LAST - 1) +enum wgdevice_monitor_flag { + WGDEVICE_MONITOR_F_ENDPOINT = 1U << 0, + __WGDEVICE_MONITOR_F_ALL = WGDEVICE_MONITOR_F_ENDPOINT +}; enum wgpeer_flag { WGPEER_F_REMOVE_ME = 1U << 0, base-commit: 1862a69c917417142190bc18c8ce16680598664b -- 2.35.1 From peljasz at yahoo.co.uk Wed Apr 13 17:45:24 2022 From: peljasz at yahoo.co.uk (lejeczek) Date: Wed, 13 Apr 2022 18:45:24 +0100 Subject: error - ? - Address already in use References: <077cdb1c-e06c-d2fd-1475-269ed744d5ca.ref@yahoo.co.uk> Message-ID: <077cdb1c-e06c-d2fd-1475-269ed744d5ca@yahoo.co.uk> Hi guys what is below error the symptom of? -> $ wg-quick up wg-r2 [#] ip link add wg-r2 type wireguard [#] wg setconf wg-r2 /dev/fd/63 [#] ip -4 address add 10.3.3.254/24 dev wg-r2 [#] ip link set mtu 1320 up dev wg-r2 RTNETLINK answers: Address already in use [#] ip link delete dev wg-r2 I'll only add that I looked into "obvious" places and found nothing. many thanks, L. From ms at kilabit.info Wed Apr 13 19:45:10 2022 From: ms at kilabit.info (Shulhan) Date: Thu, 14 Apr 2022 02:45:10 +0700 Subject: error - ? - Address already in use In-Reply-To: <077cdb1c-e06c-d2fd-1475-269ed744d5ca@yahoo.co.uk> References: <077cdb1c-e06c-d2fd-1475-269ed744d5ca.ref@yahoo.co.uk> <077cdb1c-e06c-d2fd-1475-269ed744d5ca@yahoo.co.uk> Message-ID: <20220414024510.4f980d24@inspiro.localdomain> On Wed, 13 Apr 2022 18:45:24 +0100 lejeczek wrote: > Hi guys > > what is below error the symptom of? > > -> $ wg-quick up wg-r2 > [#] ip link add wg-r2 type wireguard > [#] wg setconf wg-r2 /dev/fd/63 > [#] ip -4 address add 10.3.3.254/24 dev wg-r2 > [#] ip link set mtu 1320 up dev wg-r2 > RTNETLINK answers: Address already in use > [#] ip link delete dev wg-r2 > > I'll only add that I looked into "obvious" places and found > nothing. > many thanks, L. My guess is another wg network is already up using the same IP address. You may check using `wg show` to see the active endpoint or other net tools like `ip` or `ifconfig` to list of active net devices. -- { "github":"github.com/shuLhan", "site":"kilabit.info" } -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From peljasz at yahoo.co.uk Thu Apr 14 03:14:54 2022 From: peljasz at yahoo.co.uk (lejeczek) Date: Thu, 14 Apr 2022 04:14:54 +0100 Subject: error - ? - Address already in use In-Reply-To: <20220414024510.4f980d24@inspiro.localdomain> References: <077cdb1c-e06c-d2fd-1475-269ed744d5ca.ref@yahoo.co.uk> <077cdb1c-e06c-d2fd-1475-269ed744d5ca@yahoo.co.uk> <20220414024510.4f980d24@inspiro.localdomain> Message-ID: <20ec95e3-ce3e-8fc7-4e46-c379e719a665@yahoo.co.uk> On 13/04/2022 20:45, Shulhan wrote: > On Wed, 13 Apr 2022 18:45:24 +0100 > lejeczek wrote: > >> Hi guys >> >> what is below error the symptom of? >> >> -> $ wg-quick up wg-r2 >> [#] ip link add wg-r2 type wireguard >> [#] wg setconf wg-r2 /dev/fd/63 >> [#] ip -4 address add 10.3.3.254/24 dev wg-r2 >> [#] ip link set mtu 1320 up dev wg-r2 >> RTNETLINK answers: Address already in use >> [#] ip link delete dev wg-r2 >> >> I'll only add that I looked into "obvious" places and found >> nothing. >> many thanks, L. > My guess is another wg network is already up using the same IP address. > You may check using `wg show` to see the active endpoint or other > net tools like `ip` or `ifconfig` to list of active net devices. > This message is _pretty_ deceptive as it's the 'port' which is the culprit - if used already by instantiated wg iface. btw. @mailman admins - this mailing list has DMARC breaking, those of us who use yahoo, delivery of own messages. thanks, L From dgeor8 at gmail.com Thu Apr 14 07:46:33 2022 From: dgeor8 at gmail.com (Dan George) Date: Thu, 14 Apr 2022 17:46:33 +1000 Subject: [wireguard-apple] Reresolving DNS on device wake/network change/interval Message-ID: Hello, Is there any way when using the macOS WG apps to reresolve DNS for an endpoint on device wake, a network change event, or at a regular interval? Two options I've come across: - there's a TODO (B.4) to integrate the App Store app with wg(8) which would potentially allow the use of reresolve-dns.sh (but not yet). - scutil --nc can bounce the VPN interface in Network Preferences, which reresolves DNS, but this is disruptive to traffic. Perhaps a launchd script to run this on device wake/network change would be a good-enough solution. Any other options out there? Thanks, Dan. From Jason at zx2c4.com Thu Apr 14 11:58:04 2022 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 14 Apr 2022 13:58:04 +0200 Subject: [PATCH net 1/2] wireguard: device: fix metadata_dst xmit null pointer dereference In-Reply-To: <20220414104458.3097244-2-razor@blackwall.org> References: <20220414104458.3097244-1-razor@blackwall.org> <20220414104458.3097244-2-razor@blackwall.org> Message-ID: Hi Nikolay, On Thu, Apr 14, 2022 at 12:45 PM Nikolay Aleksandrov wrote: > When we try to transmit an skb with md_dst attached through wireguard > we hit a null pointer dereference[1] in wg_xmit() due to the use of > dst_mtu() which calls into dst_blackhole_mtu() which in turn tries to > dereference dst->dev. Since wireguard doesn't use md_dsts we should use > skb_valid_dst() which checks for DST_METADATA flag and if it's set then > fallback to wireguard's device mtu. That gives us the best chance of > transmitting the packet, otherwise if the blackhole netdev is used we'd > get ETH_MIN_MTU. Thanks for the patch. Will queue up this patch #1 in the wireguard tree and send it out to net.git not before too long. Jason From Jason at zx2c4.com Thu Apr 14 12:06:04 2022 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 14 Apr 2022 14:06:04 +0200 Subject: [PATCH net 2/2] wireguard: selftests: add metadata_dst xmit selftest In-Reply-To: <20220414104458.3097244-3-razor@blackwall.org> References: <20220414104458.3097244-1-razor@blackwall.org> <20220414104458.3097244-3-razor@blackwall.org> Message-ID: Hi Nikolay, These tests need to run in the minimal fast-to-compile test harness inside of tools/testing/selftests/wireguard/qemu, which you can try out with: $ make -C tools/testing/selftests/wireguard/qemu -j$(nproc) Currently iproute2 is built, but only ip(8) is used in the image, so you'll need to add tc(8) to there. Clang, however, seems a bit heavyweight. I suspect it'd make more sense to just base64 up that object file and include it as a string in the file? Or, alternatively, we could just not move ahead with this rather niche test, and revisit the issue if we wind up wanting to test for lots of bpf things. Thoughts on that? Jason From Jason at zx2c4.com Thu Apr 14 12:24:57 2022 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 14 Apr 2022 14:24:57 +0200 Subject: [PATCH net 2/2] wireguard: selftests: add metadata_dst xmit selftest In-Reply-To: <2607574b-6726-6772-7921-84156393df95@blackwall.org> References: <20220414104458.3097244-1-razor@blackwall.org> <20220414104458.3097244-3-razor@blackwall.org> <2607574b-6726-6772-7921-84156393df95@blackwall.org> Message-ID: On Thu, Apr 14, 2022 at 2:12 PM Nikolay Aleksandrov wrote: > My bad, I completely missed the qemu part. If you're curious, by the way, there's this running all those tests for every commit https://www.wireguard.com/build-status/ Jason From hendrik at friedels.name Sun Apr 17 08:14:26 2022 From: hendrik at friedels.name (Hendrik Friedel) Date: Sun, 17 Apr 2022 08:14:26 +0000 Subject: ipv6 vs. ipv4 Message-ID: Hello, I understood that wireguard prefers ipv6 over ipv4 by default. Nevertheless, on both Windows and Android I do not get a connection (only sent bytes no received bytes) when using my domain (friedel.dynv6.net). If I use the IP (2a00:6020:1bfb:c700:ba27:ebff:fe3e:6c55), I get a normal connection. I can imagine that WG uses ipv4 (the A-record is set, I cannot change that, but it points to an invalid ip) How can I -when using the domain- enforce that ipv6 is really used? Apart from that, my suspicion is that ipv4 is in fact used here... How can I really find out, why I get no bytes on the received counter? Best regards, Hendrik From hendrik at friedels.name Sun Apr 17 08:22:32 2022 From: hendrik at friedels.name (Hendrik Friedel) Date: Sun, 17 Apr 2022 08:22:32 +0000 Subject: Better Output Message-ID: Hello, when using wireguard - both Android and Windows - clients, I in the past often thought that the connection is fine but in fact, I had a wrong Key. The Windows-Client showed a green Checkmark under Status. The Android Client showed the "key" symbol and it showed also the "switch" on the right hand side (=activ) and blue. Obviously, the connection was not working, but I would have hoped that Wireguard would have told me, that the connection was not ok. In fact, I was only able to determine whether the connection was working by trying to access some Service (e.g. google) or by observing the "Received/bytes" counter which remained at 0. I would suggest an improvement here: 1) If no Server responds on the particular domain/IP, wireguard should show a message Could not connect to [my.domain.com] under IP [2a00:1234:1234:c700:ba27:ebff:fe3e:2342] or 1.4.4.1. 2) If a wireguard server responds, but the key is not valid it should show a message Connection failed. Host responded, but key was invalid 3) If the connection fails, the Windows Client should show a RED symbol under status. 4) If the connection fails, the "key" symbol should not be shown under Android and the toggle-switch should move from right&blue (active) back to left&grey. Would that be possible? Greetings, Hendrik From me at aaronmdjones.net Sun Apr 17 19:05:43 2022 From: me at aaronmdjones.net (Aaron Jones) Date: Sun, 17 Apr 2022 19:05:43 +0000 Subject: Better Output In-Reply-To: References: Message-ID: On 17/04/2022 08:22, Hendrik Friedel wrote: > I would suggest an improvement here: > > 1) If no Server responds on the particular domain/IP, > wireguard should show a message This would be technically achievable, but note that WireGuard uses UDP, which has no concept of "connections". See also below. > 2) If a wireguard server responds, but the key is not valid WireGuard does not respond if the keys are not valid. See section 5.1 ("Silence is a Virtue") in the WireGuard whitepaper [1]. > 3) If the connection fails, the Windows Client should show > a RED symbol under status. This could only be determined by a previously-in-use session having had no packets received for greater than the maximum rekey interval (2 minutes). However, WireGuard itself will not send any data if it has no data to send (same section of the whitepaper), and so if you are not using the tunnel for 2 minutes, this would be indistinguishable from a failed tunnel. An exception is if you enable keepalives; they are 0-length data packets. [1] https://www.wireguard.com/papers/wireguard.pdf Regards, Aaron Jones -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From hendrik at friedels.name Mon Apr 18 08:40:02 2022 From: hendrik at friedels.name (Hendrik Friedel) Date: Mon, 18 Apr 2022 08:40:02 +0000 Subject: Better Output In-Reply-To: References: Message-ID: Hello Aaron, thanks for your reply. >This would be technically achievable, but note that WireGuard >uses UDP, which has no concept of "connections". See also >below. That is understood. But one can distinguish between a situation where a (not sure about an alternative word) "connection" was established and where not. By the way: What does the Green Symbol today in the windows-client tell me? Currently, I find it totally mis-leading. I think today it only shows that: 1) the domain could be resolved to an IP 2) data was sent to it That seems not very useful. > > 2) If a wireguard server responds, but the key is not valid > >WireGuard does not respond if the keys are not valid. See >section 5.1 ("Silence is a Virtue") in the WireGuard >whitepaper [1]. Then, Silence is also a sign of a failed connection, no? --> red symbol. But ok, it cannot show the reason "key invalid". > > 3) If the connection fails, the Windows Client should show > > a RED symbol under status. > >This could only be determined by a previously-in-use session >having had no packets received for greater than the maximum >rekey interval (2 minutes). Why? If a connection is established, data is received, in my experience --> green Symbol. If no data is received --> red. Sorry, but having to check the "bytes received" and ignoring the green symbol is hardly intuitive (a bit geeky, if I may say that). The 99% user does not know the backgrounds and/or the whitepaper. >However, WireGuard itself will not send any data if it has no >data to send (same section of the whitepaper), and so if you >are not using the tunnel for 2 minutes, this would be >indistinguishable from a failed tunnel. Well, I was only thinking about the esablishing of a connection, not the situation while a tunnel is up (but not used). So, I understand that an icon that was turned green once may have to stay green (as one cannot distinguish between no data *intended* to be transmitted and no data transmitted *unintendedly*/failed connection. Unless: >An exception is if you enable keepalives; they are 0-length >data packets. In that case, the Icon would always be able to reflect the real status. Now, would that not be something for the ToDo List? Best regards, Hendrik > > >[1] https://www.wireguard.com/papers/wireguard.pdf > >Regards, >Aaron Jones > From hendrik at friedels.name Mon Apr 18 08:43:34 2022 From: hendrik at friedels.name (Hendrik Friedel) Date: Mon, 18 Apr 2022 08:43:34 +0000 Subject: ipv6 vs. ipv4 In-Reply-To: <9ff861ea-6d25-4e63-ba43-615afe1b655b@schauer.tech> References: <9ff861ea-6d25-4e63-ba43-615afe1b655b@schauer.tech> Message-ID: Hello Kilian, thanks for your reply. >the WireGuard mobile apps prefer IPv4 for connecting to the peer, since this helps roaming between networks (where many are still IPv4-only). understood. Is that documented somewhere? For the Windows-Client, I did read somewhere that ipv6 is preferred. I find it inconsistent, that the clients behave differently. >If you want to force an IPv6 transport, you either need to put a raw IPv6 address into Endpoint, or use an AAAA-only domain Intuitively, I tried [my.domain.com]:51280 in order to enforce ipv6 (just like ipv6 adresses are enclosed in []. Would that not be an enhancement to the app? Best regards, Hendrik > From aep at exys.org Wed Apr 20 08:05:30 2022 From: aep at exys.org (Arvid Picciani) Date: Wed, 20 Apr 2022 10:05:30 +0200 Subject: will frequently changing allowed-list result in latency spikes? Message-ID: Hi, we're currently using wg as point-to-point transport between thousands of vms. each peer has a separate interface so we can do BGP with bird. this works extremely well. But due to lack of port-reuse, eventually you run out of udp ports. Now i'm thinking of redesigning it with a single wg interface and using wgs native destination selection which is based on allow-list. that means every topology change results in a netlink call to wg to replace all affected peers with a new peer with a new allowed-list. In a quick test i couldn't see any problems with that. But i'm worried that might change with scale. Replacing a peer config might flush its buffer, possibly resulting in packet loss. Or more likely reset its crypto session, resulting in a latency spike until the handshake finished. anyone has more insight into that? -- +4916093821054 From brcisna at gmail.com Sat Apr 2 12:42:48 2022 From: brcisna at gmail.com (Barry Cisna) Date: Sat, 02 Apr 2022 12:42:48 -0000 Subject: hostapd compatible Message-ID: Hello All, Have been struggling trying to get WireGuard set for a peer(B) that also acts as an ltsp server to diskless clients,,running dnsmasq, which iis connected to a Google Cloud instance WireGaurd PeerA - Google Cloud Debian Bullseye static ip PeerB - local Debian Bullseye behind CGNAT cellular connection PeerB uses a cellular modem for internet wwan0 and a bridged interface for supplying dhcp to thin clients via dnsmasq bridge0 = ethernet & wlan,which in turns uses hostapd to run the wlan in master mode AP. After many hours of iptabling,multiple wired clients works fine through dnsmasq and internet through PeerB. BUT the wireless clients are super slow and most web pages never complete. Have tried all mtu settings on PeerA and PeerB and now see no fragmented hits in wireshark. It almost seems as though the MTU on the wlan interface needs to be changed, but never see any fragment hits on wireshark on the wified client? Do NOT have stp enabled on the bridge,Have not tried enabling stp. MTU 1460 seems to be the best setting for this setup,,but have read on many tuts using GCloud instance should be 1360. This MTU 1360 made web pages almost unusable for this setup. wgo-client2.conf- [Interface] PrivateKey = <> Address = 192.168.69.2/24 #Address = 10.88.88.2/24 #DNS = 10.128.0.2 #Table=off MTU = 1460 #------------------------------------------------------------------------------------------ #PostUp = ip6tables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE #PostDown = ip6tables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE # PostUp = iptables -A FORWARD -i wg0client2 -j ACCEPT # PostDown = iptables -t nat -A POSTROUTING -o wwan0 -j MASQUERADE [Peer] # Google Cloud Server PublicKey = <.> Endpoint = 35.226.##.###:51820 AllowedIPs = 0.0.0.0/0, ::/0 # Forward all traffic to server network/interfaces auto bridge0 auto wlp3s0 auto enp2s0 iface wlp3s0 inet manual iface enp2s0 inet manual #iface wlp3s0 inet6 manual #iface enp2s0 inet6 manual #bridge setup iface bridge0 inet static bridge_ports enp2s0 wlp3s0 address 192.168.67.1 broadcast 192.168.67.255 netmask 255.255.255.0 post-up iptables-restore < /etc/iptables.up.rules post-up ip6tables-restore < /etc/ip6tables.up.rules # gateway 192.168.67.1 # bridge_stp on Thanks From lenaghanm at comcast.net Sat Apr 2 18:50:39 2022 From: lenaghanm at comcast.net (lenaghanm at comcast.net) Date: Sat, 02 Apr 2022 18:50:39 -0000 Subject: Wireguard Windows Client questions Message-ID: <004a01d846c2$896fe0c0$9c4fa240$@comcast.net> Good day, this is my first posting on this list. I have read many of the past messages in the Archives but cannot find the answers I'm looking for and hoped I could get help from this list. I currently have a set up on multiple Windows PC's where the user needs to access services on multiple remote systems. Depending on the service the underlying network settings of the system may need to be changed and in some cases require connecting to a VPN server. Currently there are 2 possible VPN services (OpenVPN and SoftEtherVPN). I now need to add a 3rd option which is Wireguard. The interfaces to the VPN's are completely hidden from the users. They simply double click on an icon for the service they want to connect to and my code under the covers takes care of disconnecting any active sessions and connecting to the new one. I have read the documentation on the wireguard.exe options to see if I can develop a similar hidden mechanism to connect and disconnect from a Wireguard peer and have the following questions. 1. The documentation implies that if I executed the following command from a command line "wireguard.exe" that it will start the Manager Service and show the UI. It then states that calling wireguard.exe /installmanagerservice is suitable for silent installation but what I find is that the Management GUI is still activated and shown on the desktop. Is there anyway to start the service without the GUI window appearing? And is there anyway to prevent the UI in the system tray from being installed? 2. If for any reason the Wireguard peer is not reachable then the Handshake does not complete. When using the GUI the tunnel is shows Active but it is the tunnelservice that is active not the connection. Is there a way to limit the number of handshake retries before giving up on trying to connect? 3. From time to time the endpoint address of the peer system may have changed (I do not use a dynamic DNS service) so when trying to connect I hit the problem described in 2 above. I know what the new endpoint address is and can set it dynamically using the wg set command and the connection is then made. I would like to be able to programmatically save this change without having to manually edit the client config files. I tried using wg syncconf but get a permissions error because of the properties around the dpapi config files. Is there an alternative way to doing this short of deleting the existing dpapi file and adding a new .conf file and have the manager service encrypt it but that approach means I need to keep the private key in the clear somewhere in order to create the new conf file.\ 4. There are 2 option listed under wireguard command line options namely /managerservice and /tunnelservice CONFIG_PATH - can someone tell me what they are supposed to do every time I try running one of them I get an error popup that says - The service process could not connect to the service controller.wireguard Thanks in advance for any guidance you can give me. Regards Mike From cf.natali at gmail.com Tue Apr 5 21:21:57 2022 From: cf.natali at gmail.com (Charles-Francois Natali) Date: Tue, 05 Apr 2022 21:21:57 -0000 Subject: [PATCH] WireGuard: restrict packet handling to non-isolated CPUs. Message-ID: <20220405212129.2270-1-cf.natali@gmail.com> WireGuard currently uses round-robin to dispatch the handling of packets, handling them on all online CPUs, including isolated ones (isolcpus). This is unfortunate because it causes significant latency on isolated CPUs - see e.g. below over 240 usec: kworker/47:1-2373323 [047] 243644.756405: funcgraph_entry: | process_one_work() { kworker/47:1-2373323 [047] 243644.756406: funcgraph_entry: | wg_packet_decrypt_worker() { [...] kworker/47:1-2373323 [047] 243644.756647: funcgraph_exit: 0.591 us | } kworker/47:1-2373323 [047] 243644.756647: funcgraph_exit: ! 242.655 us | } Instead, restrict to non-isolated CPUs. Example: ~# cat /sys/devices/system/cpu/isolated 3 ~# /usr/share/doc/wireguard-tools/examples/ncat-client-server/client.sh ~# ping 192.168.4.1 Before - corresponding workqueues are executed on all CPUs: ~# trace-cmd record -p function -l wg_packet_decrypt_worker -- sleep 10 plugin 'function' CPU0 data recorded at offset=0x7d6000 4096 bytes in size CPU1 data recorded at offset=0x7d7000 4096 bytes in size CPU2 data recorded at offset=0x7d8000 4096 bytes in size CPU3 data recorded at offset=0x7d9000 4096 bytes in size ~# trace-cmd report cpus=4 kworker/3:1-52 [003] 49.784353: function: wg_packet_decrypt_worker kworker/0:1-17 [000] 50.782879: function: wg_packet_decrypt_worker kworker/1:3-162 [001] 51.783044: function: wg_packet_decrypt_worker kworker/2:1-56 [002] 52.782159: function: wg_packet_decrypt_worker kworker/3:1-52 [003] 53.780919: function: wg_packet_decrypt_worker kworker/0:0-6 [000] 54.781755: function: wg_packet_decrypt_worker kworker/1:3-162 [001] 55.781273: function: wg_packet_decrypt_worker kworker/2:1-56 [002] 56.781946: function: wg_packet_decrypt_worker kworker/3:1-52 [003] 57.781010: function: wg_packet_decrypt_worker kworker/0:0-6 [000] 58.782097: function: wg_packet_decrypt_worker ~# After - isolated CPU 3 is excluded: ~# trace-cmd record -p function -l wg_packet_decrypt_worker -- sleep 10 plugin 'function' CPU0 data recorded at offset=0x7d7000 4096 bytes in size CPU1 data recorded at offset=0x7d8000 4096 bytes in size CPU2 data recorded at offset=0x7d9000 4096 bytes in size CPU3 data recorded at offset=0x7da000 0 bytes in size ~# trace-cmd report CPU 3 is empty cpus=4 kworker/1:2-66 [001] 291.800063: function: wg_packet_decrypt_worker kworker/2:2-143 [002] 292.800266: function: wg_packet_decrypt_worker kworker/0:2-145 [000] 293.801778: function: wg_packet_decrypt_worker kworker/1:4-261 [001] 294.803411: function: wg_packet_decrypt_worker kworker/2:2-143 [002] 295.804068: function: wg_packet_decrypt_worker kworker/0:2-145 [000] 296.806057: function: wg_packet_decrypt_worker kworker/1:2-66 [001] 297.810686: function: wg_packet_decrypt_worker kworker/2:2-143 [002] 298.811602: function: wg_packet_decrypt_worker kworker/0:2-145 [000] 299.812790: function: wg_packet_decrypt_worker kworker/1:4-261 [001] 300.813076: function: wg_packet_decrypt_worker ~# Signed-off-by: Charles-Francois Natali --- drivers/net/wireguard/queueing.h | 59 +++++++++++++++++++++++++------- drivers/net/wireguard/receive.c | 2 +- 2 files changed, 48 insertions(+), 13 deletions(-) diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h index 583adb37e..106a2686c 100644 --- a/drivers/net/wireguard/queueing.h +++ b/drivers/net/wireguard/queueing.h @@ -11,6 +11,7 @@ #include #include #include +#include #include struct wg_device; @@ -102,16 +103,50 @@ static inline void wg_reset_packet(struct sk_buff *skb, bool encapsulating) skb_reset_inner_headers(skb); } -static inline int wg_cpumask_choose_online(int *stored_cpu, unsigned int id) +/* We only want to dispatch work to housekeeping CPUs, ignoring isolated ones. + */ +static inline const struct cpumask *wg_cpumask_housekeeping(void) +{ + return housekeeping_cpumask(HK_FLAG_DOMAIN); +} + +static inline int wg_cpumask_test_cpu(int cpu) +{ + return cpumask_test_cpu(cpu, cpu_online_mask) && + cpumask_test_cpu(cpu, wg_cpumask_housekeeping()); +} + +static inline unsigned int wg_cpumask_first(void) +{ + return cpumask_first_and(cpu_online_mask, wg_cpumask_housekeeping()); +} + +static inline unsigned int wg_cpumask_next(int n) +{ + return cpumask_next_and(n, cpu_online_mask, wg_cpumask_housekeeping()); +} + +static inline unsigned int wg_cpumask_weight(void) +{ + int cpu; + int weight = 0; + + for_each_cpu_and(cpu, cpu_online_mask, wg_cpumask_housekeeping()) { + ++weight; + } + + return weight; +} + +static inline int wg_cpumask_choose_eligible(int *stored_cpu, unsigned int id) { unsigned int cpu = *stored_cpu, cpu_index, i; - if (unlikely(cpu == nr_cpumask_bits || - !cpumask_test_cpu(cpu, cpu_online_mask))) { - cpu_index = id % cpumask_weight(cpu_online_mask); - cpu = cpumask_first(cpu_online_mask); + if (unlikely(cpu == nr_cpumask_bits || !wg_cpumask_test_cpu(cpu))) { + cpu_index = id % wg_cpumask_weight(); + cpu = wg_cpumask_first(); for (i = 0; i < cpu_index; ++i) - cpu = cpumask_next(cpu, cpu_online_mask); + cpu = wg_cpumask_next(cpu); *stored_cpu = cpu; } return cpu; @@ -124,13 +159,13 @@ static inline int wg_cpumask_choose_online(int *stored_cpu, unsigned int id) * a bit slower, and it doesn't seem like this potential race actually * introduces any performance loss, so we live with it. */ -static inline int wg_cpumask_next_online(int *next) +static inline int wg_cpumask_next_eligible(int *next) { int cpu = *next; - while (unlikely(!cpumask_test_cpu(cpu, cpu_online_mask))) - cpu = cpumask_next(cpu, cpu_online_mask) % nr_cpumask_bits; - *next = cpumask_next(cpu, cpu_online_mask) % nr_cpumask_bits; + while (unlikely(!wg_cpumask_test_cpu(cpu))) + cpu = wg_cpumask_next(cpu) % nr_cpumask_bits; + *next = wg_cpumask_next(cpu) % nr_cpumask_bits; return cpu; } @@ -173,7 +208,7 @@ static inline int wg_queue_enqueue_per_device_and_peer( /* Then we queue it up in the device queue, which consumes the * packet as soon as it can. */ - cpu = wg_cpumask_next_online(next_cpu); + cpu = wg_cpumask_next_eligible(next_cpu); if (unlikely(ptr_ring_produce_bh(&device_queue->ring, skb))) return -EPIPE; queue_work_on(cpu, wq, &per_cpu_ptr(device_queue->worker, cpu)->work); @@ -188,7 +223,7 @@ static inline void wg_queue_enqueue_per_peer_tx(struct sk_buff *skb, enum packet struct wg_peer *peer = wg_peer_get(PACKET_PEER(skb)); atomic_set_release(&PACKET_CB(skb)->state, state); - queue_work_on(wg_cpumask_choose_online(&peer->serial_work_cpu, peer->internal_id), + queue_work_on(wg_cpumask_choose_eligible(&peer->serial_work_cpu, peer->internal_id), peer->device->packet_crypt_wq, &peer->transmit_packet_work); wg_peer_put(peer); } diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c index 7b8df406c..2d5d903d0 100644 --- a/drivers/net/wireguard/receive.c +++ b/drivers/net/wireguard/receive.c @@ -572,7 +572,7 @@ void wg_packet_receive(struct wg_device *wg, struct sk_buff *skb) goto err; } atomic_inc(&wg->handshake_queue_len); - cpu = wg_cpumask_next_online(&wg->handshake_queue.last_cpu); + cpu = wg_cpumask_next_eligible(&wg->handshake_queue.last_cpu); /* Queues up a call to packet_process_queued_handshake_packets(skb): */ queue_work_on(cpu, wg->handshake_receive_wq, &per_cpu_ptr(wg->handshake_queue.worker, cpu)->work); -- 2.30.2 From brook.qin at gmail.com Wed Apr 6 08:02:01 2022 From: brook.qin at gmail.com (Brook Q) Date: Wed, 06 Apr 2022 08:02:01 -0000 Subject: [PATCH 0/1] Convert network ip string to submenu list Message-ID: <20220406080110.8705-1-brook.qin@gmail.com> Hi, Wireguard been a great help to me for working from home, many thanks to wiredguard team. In my situation, allowedIPs contains many IP addresses, and as a string is too long in menu title, maybe convert it to submenu list is better. https://imgur.com/a/bKdxeG8 Sincerely Brook Q (1): UI: macOS: move tunnel peers ip to submenus Sources/WireGuardApp/Base.lproj/Localizable.strings | 1 + Sources/WireGuardApp/UI/macOS/StatusMenu.swift | 13 ++++++++++--- Sources/WireGuardApp/de.lproj/Localizable.strings | 1 + Sources/WireGuardApp/fa.lproj/Localizable.strings | 1 + Sources/WireGuardApp/fi.lproj/Localizable.strings | 1 + Sources/WireGuardApp/fr.lproj/Localizable.strings | 1 + Sources/WireGuardApp/it.lproj/Localizable.strings | 1 + Sources/WireGuardApp/ja.lproj/Localizable.strings | 1 + Sources/WireGuardApp/pa.lproj/Localizable.strings | 1 + Sources/WireGuardApp/pl.lproj/Localizable.strings | 1 + Sources/WireGuardApp/ro.lproj/Localizable.strings | 1 + Sources/WireGuardApp/ru.lproj/Localizable.strings | 1 + Sources/WireGuardApp/sl.lproj/Localizable.strings | 1 + Sources/WireGuardApp/tr.lproj/Localizable.strings | 1 + .../WireGuardApp/zh-Hans.lproj/Localizable.strings | 1 + .../WireGuardApp/zh-Hant.lproj/Localizable.strings | 1 + 16 files changed, 25 insertions(+), 3 deletions(-) -- 2.32.0 (Apple Git-132) From brook.qin at gmail.com Wed Apr 6 08:03:18 2022 From: brook.qin at gmail.com (Brook Q) Date: Wed, 06 Apr 2022 08:03:18 -0000 Subject: [PATCH 1/1] UI: macOS: move tunnel peers ip to submenus In-Reply-To: <20220406080110.8705-1-brook.qin@gmail.com> References: <20220406080110.8705-1-brook.qin@gmail.com> Message-ID: <20220406080110.8705-2-brook.qin@gmail.com> Sometimes allowdIPs as a string is too long as menu title, maybe convert to submenu list is better. --- Sources/WireGuardApp/Base.lproj/Localizable.strings | 1 + Sources/WireGuardApp/UI/macOS/StatusMenu.swift | 13 ++++++++++--- Sources/WireGuardApp/de.lproj/Localizable.strings | 1 + Sources/WireGuardApp/fa.lproj/Localizable.strings | 1 + Sources/WireGuardApp/fi.lproj/Localizable.strings | 1 + Sources/WireGuardApp/fr.lproj/Localizable.strings | 1 + Sources/WireGuardApp/it.lproj/Localizable.strings | 1 + Sources/WireGuardApp/ja.lproj/Localizable.strings | 1 + Sources/WireGuardApp/pa.lproj/Localizable.strings | 1 + Sources/WireGuardApp/pl.lproj/Localizable.strings | 1 + Sources/WireGuardApp/ro.lproj/Localizable.strings | 1 + Sources/WireGuardApp/ru.lproj/Localizable.strings | 1 + Sources/WireGuardApp/sl.lproj/Localizable.strings | 1 + Sources/WireGuardApp/tr.lproj/Localizable.strings | 1 + .../WireGuardApp/zh-Hans.lproj/Localizable.strings | 1 + .../WireGuardApp/zh-Hant.lproj/Localizable.strings | 1 + 16 files changed, 25 insertions(+), 3 deletions(-) diff --git a/Sources/WireGuardApp/Base.lproj/Localizable.strings b/Sources/WireGuardApp/Base.lproj/Localizable.strings index 40023ec..3db7659 100644 --- a/Sources/WireGuardApp/Base.lproj/Localizable.strings +++ b/Sources/WireGuardApp/Base.lproj/Localizable.strings @@ -301,6 +301,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "Networks"; "macMenuNetworks (%@)" = "Networks: %@"; "macMenuNetworksNone" = "Networks: None"; diff --git a/Sources/WireGuardApp/UI/macOS/StatusMenu.swift b/Sources/WireGuardApp/UI/macOS/StatusMenu.swift index 6cd00a4..b74877d 100644 --- a/Sources/WireGuardApp/UI/macOS/StatusMenu.swift +++ b/Sources/WireGuardApp/UI/macOS/StatusMenu.swift @@ -107,12 +107,19 @@ class StatusMenu: NSMenu { networksMenuItem.title = "" networksMenuItem.isHidden = true } else { - let allowedIPs = tunnel.tunnelConfiguration?.peers.flatMap { $0.allowedIPs }.map { $0.stringRepresentation }.joined(separator: ", ") ?? "" - if !allowedIPs.isEmpty { - networksMenuItem.title = tr(format: "macMenuNetworks (%@)", allowedIPs) + networksMenuItem.submenu?.items.removeAll() + let allowedIPs = tunnel.tunnelConfiguration?.peers.flatMap { $0.allowedIPs }.map { $0.stringRepresentation } ?? [] + if allowedIPs.count > 0 { + networksMenuItem.title = tr("macMenuNetworks") + allowedIPs.forEach { ip in + let networkSubItem = NSMenuItem(title: ip, action: nil, keyEquivalent: "") + networkSubItem.isEnabled = false + networksMenuItem.submenu?.addItem(networkSubItem) + } } else { networksMenuItem.title = tr("macMenuNetworksNone") } + networksMenuItem.isEnabled = (networksMenuItem.submenu?.items.count ?? 0) > 0 networksMenuItem.isHidden = false } deactivateMenuItem.isHidden = tunnel.status != .active diff --git a/Sources/WireGuardApp/de.lproj/Localizable.strings b/Sources/WireGuardApp/de.lproj/Localizable.strings index ffcb429..2f0ee1d 100644 --- a/Sources/WireGuardApp/de.lproj/Localizable.strings +++ b/Sources/WireGuardApp/de.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "Netzwerke"; "macMenuNetworks (%@)" = "Netzwerke:%@"; "macMenuNetworksNone" = "Keine Netzwerke."; diff --git a/Sources/WireGuardApp/fa.lproj/Localizable.strings b/Sources/WireGuardApp/fa.lproj/Localizable.strings index 43bd393..6cfda75 100644 --- a/Sources/WireGuardApp/fa.lproj/Localizable.strings +++ b/Sources/WireGuardApp/fa.lproj/Localizable.strings @@ -235,6 +235,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "???????"; "macMenuNetworks (%@)" = "???????: %@"; "macMenuNetworksNone" = "???????: ????"; diff --git a/Sources/WireGuardApp/fi.lproj/Localizable.strings b/Sources/WireGuardApp/fi.lproj/Localizable.strings index b359675..6600f3c 100644 --- a/Sources/WireGuardApp/fi.lproj/Localizable.strings +++ b/Sources/WireGuardApp/fi.lproj/Localizable.strings @@ -244,6 +244,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "Verkot"; "macMenuNetworks (%@)" = "Verkot: %@"; "macMenuNetworksNone" = "Verkot: Ei mit??n"; diff --git a/Sources/WireGuardApp/fr.lproj/Localizable.strings b/Sources/WireGuardApp/fr.lproj/Localizable.strings index aeeed29..335d061 100644 --- a/Sources/WireGuardApp/fr.lproj/Localizable.strings +++ b/Sources/WireGuardApp/fr.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "R?seaux"; "macMenuNetworks (%@)" = "R?seaux: %@"; "macMenuNetworksNone" = "R?seaux: Aucun"; diff --git a/Sources/WireGuardApp/it.lproj/Localizable.strings b/Sources/WireGuardApp/it.lproj/Localizable.strings index 68acfc2..14a74c6 100644 --- a/Sources/WireGuardApp/it.lproj/Localizable.strings +++ b/Sources/WireGuardApp/it.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "Reti"; "macMenuNetworks (%@)" = "Reti: %@"; "macMenuNetworksNone" = "Reti: nessuna"; diff --git a/Sources/WireGuardApp/ja.lproj/Localizable.strings b/Sources/WireGuardApp/ja.lproj/Localizable.strings index be5d30b..c729a88 100644 --- a/Sources/WireGuardApp/ja.lproj/Localizable.strings +++ b/Sources/WireGuardApp/ja.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "??????"; "macMenuNetworks (%@)" = "??????: %@"; "macMenuNetworksNone" = "??????: ??"; diff --git a/Sources/WireGuardApp/pa.lproj/Localizable.strings b/Sources/WireGuardApp/pa.lproj/Localizable.strings index 54cef5f..76dbc64 100644 --- a/Sources/WireGuardApp/pa.lproj/Localizable.strings +++ b/Sources/WireGuardApp/pa.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "???????"; "macMenuNetworks (%@)" = "???????: %@"; "macMenuNetworksNone" = "???????: ??? ????"; diff --git a/Sources/WireGuardApp/pl.lproj/Localizable.strings b/Sources/WireGuardApp/pl.lproj/Localizable.strings index 550344a..dddca13 100644 --- a/Sources/WireGuardApp/pl.lproj/Localizable.strings +++ b/Sources/WireGuardApp/pl.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "Sieci"; "macMenuNetworks (%@)" = "Sieci: %@"; "macMenuNetworksNone" = "Sieci: brak"; diff --git a/Sources/WireGuardApp/ro.lproj/Localizable.strings b/Sources/WireGuardApp/ro.lproj/Localizable.strings index 0b0843f..53ec584 100644 --- a/Sources/WireGuardApp/ro.lproj/Localizable.strings +++ b/Sources/WireGuardApp/ro.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "Re?ele"; "macMenuNetworks (%@)" = "Re?ele: %@"; "macMenuNetworksNone" = "Re?ele: niciuna"; diff --git a/Sources/WireGuardApp/ru.lproj/Localizable.strings b/Sources/WireGuardApp/ru.lproj/Localizable.strings index aa18919..906a938 100644 --- a/Sources/WireGuardApp/ru.lproj/Localizable.strings +++ b/Sources/WireGuardApp/ru.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "????"; "macMenuNetworks (%@)" = "????: %@"; "macMenuNetworksNone" = "???? ???????????"; diff --git a/Sources/WireGuardApp/sl.lproj/Localizable.strings b/Sources/WireGuardApp/sl.lproj/Localizable.strings index b57da97..36ff8e7 100644 --- a/Sources/WireGuardApp/sl.lproj/Localizable.strings +++ b/Sources/WireGuardApp/sl.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "Omre?ja"; "macMenuNetworks (%@)" = "Omre?ja: %@"; "macMenuNetworksNone" = "Ni omre?ij"; diff --git a/Sources/WireGuardApp/tr.lproj/Localizable.strings b/Sources/WireGuardApp/tr.lproj/Localizable.strings index 537d28c..be52bb5 100644 --- a/Sources/WireGuardApp/tr.lproj/Localizable.strings +++ b/Sources/WireGuardApp/tr.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "A?lar"; "macMenuNetworks (%@)" = "A?lar: %@"; "macMenuNetworksNone" = "A?lar: Yok"; diff --git a/Sources/WireGuardApp/zh-Hans.lproj/Localizable.strings b/Sources/WireGuardApp/zh-Hans.lproj/Localizable.strings index 1f97382..557b492 100644 --- a/Sources/WireGuardApp/zh-Hans.lproj/Localizable.strings +++ b/Sources/WireGuardApp/zh-Hans.lproj/Localizable.strings @@ -291,6 +291,7 @@ // Mac status bar menu / pulldown menu / main menu +"macMenuNetworks" = "??"; "macMenuNetworks (%@)" = "???%@"; "macMenuNetworksNone" = "????"; diff --git a/Sources/WireGuardApp/zh-Hant.lproj/Localizable.strings b/Sources/WireGuardApp/zh-Hant.lproj/Localizable.strings index 5aef8b4..a526d5a 100644 --- a/Sources/WireGuardApp/zh-Hant.lproj/Localizable.strings +++ b/Sources/WireGuardApp/zh-Hant.lproj/Localizable.strings @@ -176,6 +176,7 @@ "alertUnableToWriteLogTitle" = "Log export failed"; "alertInvalidPeerMessagePublicKeyRequired" = "Peer?s public key is required"; "macMenuNetworksNone" = "Networks: None"; +"macMenuNetworks" = "Networks"; "tunnelOnDemandSSIDsKey" = "SSIDs"; "alertCantOpenOutputZipFileForWritingMessage" = "Could not open zip file for writing."; "logViewTitle" = "Log"; -- 2.32.0 (Apple Git-132) From daniel at iogearbox.net Thu Apr 14 11:28:18 2022 From: daniel at iogearbox.net (Daniel Borkmann) Date: Thu, 14 Apr 2022 13:28:18 +0200 Subject: [PATCH net 1/2] wireguard: device: fix metadata_dst xmit null pointer dereference In-Reply-To: <20220414104458.3097244-2-razor@blackwall.org> References: <20220414104458.3097244-1-razor@blackwall.org> <20220414104458.3097244-2-razor@blackwall.org> Message-ID: <24cac92b-4981-4ddc-9a05-32b61799e688@iogearbox.net> On 4/14/22 12:44 PM, Nikolay Aleksandrov wrote: > When we try to transmit an skb with md_dst attached through wireguard > we hit a null pointer dereference[1] in wg_xmit() due to the use of > dst_mtu() which calls into dst_blackhole_mtu() which in turn tries to > dereference dst->dev. Since wireguard doesn't use md_dsts we should use > skb_valid_dst() which checks for DST_METADATA flag and if it's set then > fallback to wireguard's device mtu. That gives us the best chance of > transmitting the packet, otherwise if the blackhole netdev is used we'd > get ETH_MIN_MTU. > [...] > > CC: stable at vger.kernel.org > CC: wireguard at lists.zx2c4.com > CC: Jason A. Donenfeld > CC: Daniel Borkmann > CC: Martynas Pumputis > Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") > Reported-by: Martynas Pumputis > Signed-off-by: Nikolay Aleksandrov Looks good to me, thanks Nik! Acked-by: Daniel Borkmann From kilian at schauer.tech Sun Apr 17 09:26:57 2022 From: kilian at schauer.tech (Kilian Schauer) Date: Sun, 17 Apr 2022 09:26:57 +0000 (UTC) Subject: ipv6 vs. ipv4 In-Reply-To: References: Message-ID: <9ff861ea-6d25-4e63-ba43-615afe1b655b@schauer.tech> 17.04.2022 10:20:03 Hendrik Friedel : > Hello, > > I understood that wireguard prefers ipv6 over ipv4 by default. > Nevertheless, on both Windows and Android I do not get a connection (only sent bytes no received bytes) when using my domain (friedel.dynv6.net). If I use the IP (2a00:6020:1bfb:c700:ba27:ebff:fe3e:6c55), I get a normal connection. > I can imagine that WG uses ipv4 (the A-record is set, I cannot change that, but it points to an invalid ip) > > How can I -when using the domain- enforce that ipv6 is really used? > > Apart from that, my suspicion is that ipv4 is in fact used here... How can I really find out, why I get no bytes on the received counter? > > Best regards, > Hendrik Hi Hendrik, the WireGuard mobile apps prefer IPv4 for connecting to the peer, since this helps roaming between networks (where many are still IPv4-only). If the A record of the Endpoint domain is broken, it won't work. If you want to force an IPv6 transport, you either need to put a raw IPv6 address into Endpoint, or use an AAAA-only domain. Hope this helps, Kilian From dimitri.papadopoulos at cea.fr Wed Apr 20 09:20:54 2022 From: dimitri.papadopoulos at cea.fr (Dimitri Papadopoulos Orfanos) Date: Wed, 20 Apr 2022 11:20:54 +0200 Subject: Wintun on Windows 11 Message-ID: <367df062-5c7c-2916-db4d-afdf6c7d92db@cea.fr> Hi, The README states that Wintun "is a layer 3 TUN driver for Windows 7, 8, 8.1, and 10": https://git.zx2c4.com/wintun/tree/README.md#n4 You should add Windows 11 to the list. Best Regards, Dimitri From s.lindhorst at wut.de Thu Apr 7 08:07:27 2022 From: s.lindhorst at wut.de (Simon Lindhorst) Date: Thu, 7 Apr 2022 10:07:27 +0200 Subject: odd behaviour for PSK with wg syncconf Message-ID: <03fa1a4e-1693-0016-73eb-49bf9bdc7615@wut.de> Hi, I tried a little bit around with PresharedKeys an found an odd behaviour when I use /wg syncconf/ instead of /wg setconf./ My config: /[Interface]// //PrivateKey = yGKbadTuMvT6JWven0yh8tJMFMCnpYoDizueu4K9QF0=// //Listenport = 4444// // //[Peer]// //PublicKey = Ts7VwZt8Q2QB5fTydQEfTgqfz1u4WIL6YMQKlMKZ6E8=// //AllowedIPs = 10.10.10.2,192.168.10.0/24,192.168.0.0/24// //PresharedKey=oipUDdsUPj1lYZMSN2jdx66OSvARhRpso2GD1frE3xo=/ /wg setconf /leads to: //root # wg showconf wg0 [Interface] ListenPort = 4444 PrivateKey = yGKbadTuMvT6JWven0yh8tJMFMCnpYoDizueu4K9QF0= [Peer] PublicKey = Ts7VwZt8Q2QB5fTydQEfTgqfz1u4WIL6YMQKlMKZ6E8= PresharedKey = oipUDdsUPj1lYZMSN2jdx66OSvARhRpso2GD1frE3xo= AllowedIPs = 10.10.10.2/32, 192.168.10.0/24, 192.168.0.0/24 Endpoint = 10.40.28.51:37842/ When I comment out the PresharedKey and do //root # wg syncconf wg0 "/etc/vpn/wg0.conf"/ I get //root # wg showconf wg0// //[Interface]// //ListenPort = 4444// //PrivateKey = yGKbadTuMvT6JWven0yh8tJMFMCnpYoDizueu4K9QF0=// // //[Peer]// //PublicKey = Ts7VwZt8Q2QB5fTydQEfTgqfz1u4WIL6YMQKlMKZ6E8=// //PresharedKey = oipUDdsUPj1lYZMSN2jdx66OSvARhRpso2GD1frE3xo=// //AllowedIPs = 10.10.10.2/32, 192.168.10.0/24, 192.168.0.0/24// //Endpoint = 10.40.28.51:37842/ The PSK entry is always there. But when I change the PSK in the config file the PSK entry is correctly changed in /wg showconf/ output after call /wg syncconf/. Is there a reason for this behaviour? Kind regards S. -- Unsere Aussagen koennen Irrtuemer und Missverstaendnisse enthalten. Bitte pruefen Sie die Aussagen fuer Ihren Fall, bevor Sie Entscheidungen auf Grundlage dieser Aussagen treffen. Wiesemann & Theis GmbH, Porschestr. 12, D-42279 Wuppertal Geschaeftsfuehrer: Dipl.-Ing. Ruediger Theis Registergericht: Amtsgericht Wuppertal, HRB 6377 Infos zum Datenschutz: https://www.wut.de/datenschutz Tel. +49-202/2680-0, Fax +49-202/2680-265, https://www.wut.de From razor at blackwall.org Thu Apr 14 10:44:56 2022 From: razor at blackwall.org (Nikolay Aleksandrov) Date: Thu, 14 Apr 2022 13:44:56 +0300 Subject: [PATCH net 0/2] wireguard: device: fix metadata_dst xmit null pointer dereference Message-ID: <20220414104458.3097244-1-razor@blackwall.org> Hi, Patch 01 fixes a null pointer dereference in wireguard's xmit path when transmitting skbs with metadata_dst attached. Patch 02 adds a selftest for that case using bpf_skb_set_tunnel_key on wg device's egress path. Thanks, Nik Nikolay Aleksandrov (2): wireguard: device: fix metadata_dst xmit null pointer dereference wireguard: selftests: add metadata_dst xmit selftest drivers/net/wireguard/device.c | 3 +- tools/testing/selftests/wireguard/netns.sh | 63 ++++++++++++++++++++++ 2 files changed, 65 insertions(+), 1 deletion(-) -- 2.35.1 From razor at blackwall.org Thu Apr 14 10:44:57 2022 From: razor at blackwall.org (Nikolay Aleksandrov) Date: Thu, 14 Apr 2022 13:44:57 +0300 Subject: [PATCH net 1/2] wireguard: device: fix metadata_dst xmit null pointer dereference In-Reply-To: <20220414104458.3097244-1-razor@blackwall.org> References: <20220414104458.3097244-1-razor@blackwall.org> Message-ID: <20220414104458.3097244-2-razor@blackwall.org> When we try to transmit an skb with md_dst attached through wireguard we hit a null pointer dereference[1] in wg_xmit() due to the use of dst_mtu() which calls into dst_blackhole_mtu() which in turn tries to dereference dst->dev. Since wireguard doesn't use md_dsts we should use skb_valid_dst() which checks for DST_METADATA flag and if it's set then fallback to wireguard's device mtu. That gives us the best chance of transmitting the packet, otherwise if the blackhole netdev is used we'd get ETH_MIN_MTU. [1] calltrace: [ 263.693506] BUG: kernel NULL pointer dereference, address: 00000000000000e0 [ 263.693908] #PF: supervisor read access in kernel mode [ 263.694174] #PF: error_code(0x0000) - not-present page [ 263.694424] PGD 0 P4D 0 [ 263.694653] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 263.694876] CPU: 5 PID: 951 Comm: mausezahn Kdump: loaded Not tainted 5.18.0-rc1+ #522 [ 263.695190] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1.fc35 04/01/2014 [ 263.695529] RIP: 0010:dst_blackhole_mtu+0x17/0x20 [ 263.695770] Code: 00 00 00 0f 1f 44 00 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 47 10 48 83 e0 fc 8b 40 04 85 c0 75 09 48 8b 07 <8b> 80 e0 00 00 00 c3 66 90 0f 1f 44 00 00 48 89 d7 be 01 00 00 00 [ 263.696339] RSP: 0018:ffffa4a4422fbb28 EFLAGS: 00010246 [ 263.696600] RAX: 0000000000000000 RBX: ffff8ac9c3553000 RCX: 0000000000000000 [ 263.696891] RDX: 0000000000000401 RSI: 00000000fffffe01 RDI: ffffc4a43fb48900 [ 263.697178] RBP: ffffa4a4422fbb90 R08: ffffffff9622635e R09: 0000000000000002 [ 263.697469] R10: ffffffff9b69a6c0 R11: ffffa4a4422fbd0c R12: ffff8ac9d18b1a00 [ 263.697766] R13: ffff8ac9d0ce1840 R14: ffff8ac9d18b1a00 R15: ffff8ac9c3553000 [ 263.698054] FS: 00007f3704c337c0(0000) GS:ffff8acaebf40000(0000) knlGS:0000000000000000 [ 263.698470] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 263.698826] CR2: 00000000000000e0 CR3: 0000000117a5c000 CR4: 00000000000006e0 [ 263.699214] Call Trace: [ 263.699505] [ 263.699759] wg_xmit+0x411/0x450 [ 263.700059] ? bpf_skb_set_tunnel_key+0x46/0x2d0 [ 263.700382] ? dev_queue_xmit_nit+0x31/0x2b0 [ 263.700719] dev_hard_start_xmit+0xd9/0x220 [ 263.701047] __dev_queue_xmit+0x8b9/0xd30 [ 263.701344] __bpf_redirect+0x1a4/0x380 [ 263.701664] __dev_queue_xmit+0x83b/0xd30 [ 263.701961] ? packet_parse_headers+0xb4/0xf0 [ 263.702275] packet_sendmsg+0x9a8/0x16a0 [ 263.702596] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 263.702933] sock_sendmsg+0x5e/0x60 [ 263.703239] __sys_sendto+0xf0/0x160 [ 263.703549] __x64_sys_sendto+0x20/0x30 [ 263.703853] do_syscall_64+0x3b/0x90 [ 263.704162] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 263.704494] RIP: 0033:0x7f3704d50506 [ 263.704789] Code: 48 c7 c0 ff ff ff ff eb b7 66 2e 0f 1f 84 00 00 00 00 00 90 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 72 c3 90 55 48 83 ec 30 44 89 4c 24 2c 4c 89 [ 263.705652] RSP: 002b:00007ffe954b0b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 263.706141] RAX: ffffffffffffffda RBX: 0000558bb259b490 RCX: 00007f3704d50506 [ 263.706544] RDX: 000000000000004a RSI: 0000558bb259b7b2 RDI: 0000000000000003 [ 263.706952] RBP: 0000000000000000 R08: 00007ffe954b0b90 R09: 0000000000000014 [ 263.707339] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe954b0b90 [ 263.707735] R13: 000000000000004a R14: 0000558bb259b7b2 R15: 0000000000000001 [ 263.708132] [ 263.708398] Modules linked in: bridge netconsole bonding [last unloaded: bridge] [ 263.708942] CR2: 00000000000000e0 CC: stable at vger.kernel.org CC: wireguard at lists.zx2c4.com CC: Jason A. Donenfeld CC: Daniel Borkmann CC: Martynas Pumputis Fixes: e7096c131e51 ("net: WireGuard secure network tunnel") Reported-by: Martynas Pumputis Signed-off-by: Nikolay Aleksandrov --- drivers/net/wireguard/device.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c index 0fad1331303c..aa9a7a5970fd 100644 --- a/drivers/net/wireguard/device.c +++ b/drivers/net/wireguard/device.c @@ -19,6 +19,7 @@ #include #include #include +#include #include #include #include @@ -167,7 +168,7 @@ static netdev_tx_t wg_xmit(struct sk_buff *skb, struct net_device *dev) goto err_peer; } - mtu = skb_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu; + mtu = skb_valid_dst(skb) ? dst_mtu(skb_dst(skb)) : dev->mtu; __skb_queue_head_init(&packets); if (!skb_is_gso(skb)) { -- 2.35.1 From razor at blackwall.org Thu Apr 14 10:44:58 2022 From: razor at blackwall.org (Nikolay Aleksandrov) Date: Thu, 14 Apr 2022 13:44:58 +0300 Subject: [PATCH net 2/2] wireguard: selftests: add metadata_dst xmit selftest In-Reply-To: <20220414104458.3097244-1-razor@blackwall.org> References: <20220414104458.3097244-1-razor@blackwall.org> Message-ID: <20220414104458.3097244-3-razor@blackwall.org> Add a selftest for transmitting skb with md_dst attached. It is done via a bpf program which uses bpf_skb_set_tunnel_key on wireguard's egress path. It requires clang and tc to be installed. If the test finishes without a crash it is considered successful. CC: wireguard at lists.zx2c4.com CC: Jason A. Donenfeld CC: Daniel Borkmann CC: Martynas Pumputis Signed-off-by: Nikolay Aleksandrov --- Executed the prep compilation commands with n1 to make them visible. tools/testing/selftests/wireguard/netns.sh | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) diff --git a/tools/testing/selftests/wireguard/netns.sh b/tools/testing/selftests/wireguard/netns.sh index 8a9461aa0878..b492dbb94245 100755 --- a/tools/testing/selftests/wireguard/netns.sh +++ b/tools/testing/selftests/wireguard/netns.sh @@ -156,6 +156,67 @@ tests() { done } +md_dst_test_cleanup() { + rm -rf /tmp/test_wg_tun.c /tmp/test_wg_tun.ll /tmp/test_wg_tun.o + n1 tc qdisc del dev wg0 clsact +} + +# test for md dst on wireguard's egress path +md_dst_test() { + # clang is required for the test + if [[ ! -x "$(command -v "clang")" ]]; then + return + fi + + # attach md dst to the skb on egress using bpf_skb_set_tunnel_key + n1 cat > /tmp/test_wg_tun.c < + +#ifndef TC_ACT_OK +# define TC_ACT_OK 0 +#endif + +static long (*bpf_skb_set_tunnel_key)(struct __sk_buff *skb, struct bpf_tunnel_key *key, __u32 size, __u64 flags) = (void *) 21; + +__attribute__((section("egress"), used)) +int tc_egress(struct __sk_buff *skb) +{ + struct bpf_tunnel_key key = {}; + + bpf_skb_set_tunnel_key(skb, &key, sizeof(key), 0); + + return TC_ACT_OK; +} + +char __license[] __attribute__((section("license"), used)) = "GPL"; +EOF + + n1 clang -O2 -emit-llvm -c /tmp/test_wg_tun.c -o /tmp/test_wg_tun.ll + if [[ ! -f "/tmp/test_wg_tun.ll" ]]; then + md_dst_test_cleanup + return + fi + n1 llc -march=bpf -filetype=obj -o /tmp/test_wg_tun.o /tmp/test_wg_tun.ll + if [[ ! -f "/tmp/test_wg_tun.o" ]]; then + md_dst_test_cleanup + return + fi + + n1 tc qdisc add dev wg0 clsact + if [[ $? -ne 0 ]]; then + md_dst_test_cleanup + return + fi + n1 tc filter add dev wg0 egress basic action bpf obj /tmp/test_wg_tun.o sec egress + if [[ $? -ne 0 ]]; then + md_dst_test_cleanup + return + fi + n1 ping -c 2 -f -W 1 192.168.241.2 + # if we reach here without a crash the test passed + md_dst_test_cleanup +} + [[ $(ip1 link show dev wg0) =~ mtu\ ([0-9]+) ]] && orig_mtu="${BASH_REMATCH[1]}" big_mtu=$(( 34816 - 1500 + $orig_mtu )) @@ -175,6 +236,8 @@ read _ rx_bytes tx_bytes < <(n1 wg show wg0 transfer) read _ timestamp < <(n1 wg show wg0 latest-handshakes) (( timestamp != 0 )) +md_dst_test + tests ip1 link set wg0 mtu $big_mtu ip2 link set wg0 mtu $big_mtu -- 2.35.1 From razor at blackwall.org Thu Apr 14 12:12:39 2022 From: razor at blackwall.org (Nikolay Aleksandrov) Date: Thu, 14 Apr 2022 15:12:39 +0300 Subject: [PATCH net 2/2] wireguard: selftests: add metadata_dst xmit selftest In-Reply-To: References: <20220414104458.3097244-1-razor@blackwall.org> <20220414104458.3097244-3-razor@blackwall.org> Message-ID: <2607574b-6726-6772-7921-84156393df95@blackwall.org> On 14/04/2022 15:06, Jason A. Donenfeld wrote: > Hi Nikolay, > > These tests need to run in the minimal fast-to-compile test harness > inside of tools/testing/selftests/wireguard/qemu, which you can try > out with: > > $ make -C tools/testing/selftests/wireguard/qemu -j$(nproc) > > Currently iproute2 is built, but only ip(8) is used in the image, so > you'll need to add tc(8) to there. Clang, however, seems a bit > heavyweight. I suspect it'd make more sense to just base64 up that > object file and include it as a string in the file? Or, alternatively, > we could just not move ahead with this rather niche test, and revisit > the issue if we wind up wanting to test for lots of bpf things. > Thoughts on that? > > Jason Hi Jason, My bad, I completely missed the qemu part. I'll look into including the ready object file. If it works out, looks compact and well I'll post v2. Thanks, Nik From nohktwo at gmail.com Mon Apr 18 02:12:21 2022 From: nohktwo at gmail.com (Nohk Two) Date: Mon, 18 Apr 2022 10:12:21 +0800 Subject: Is it possible to disable wireguard on specific Wi-Fi ? Message-ID: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> Hello, I setup a wireguard server at home and has a public IP address. This server allows the clients to access my LAN (e.g. 192.168.87.0/24) and configuring the DNS servers as my DNS servers in my LAN (e.g. 192.168.87.1 and 192.168.87.2). My family members use their phones (iPhone and Android) to connect to my LAN via the Wireguard for iOS/Android App. And this worked perfectly while the phones are using the 4G/5G network. But when the phones connect to the Wi-Fi of my home's router, the DHCP assigns the IP addresses as 192.168.87.0/24, it's my LAN, to the phones. In this situation, phones' owners should manually turn off their Wireguard connection to have the internet accessing. I guess there are something conflict because the vanilla IP network and the allowed IP network are the same. So, I have this idea that if it is possible to configure the Wireguard app to turn off or disable automatically when the network is established on specific Wi-Fi SSIDs ? Or do you have better ideas ? Thanks. From synfinatic at gmail.com Thu Apr 7 00:05:46 2022 From: synfinatic at gmail.com (Aaron Turner) Date: Wed, 6 Apr 2022 17:05:46 -0700 Subject: Wireguard crashing MacOS when going to sleep and tunnel active Message-ID: I asked on the #wireguard channel and was told to post here like it's 1999, but here it goes: MacOS Catalina / 10.15.7 MacBook Pro 16"/ 2019 (intel) Wireguard from Apple Store v1.0.15 (26) Recently switched from using OpenVPN to Wireguard. Since then, I've twice had my computer reboot upon wake-up which is definitely a new behavior. The only commonality I can think of is that both times I had a Wireguard tunnel active when I closed the screen to put it to sleep. Not getting a kernel panic/report to Apple message upon booting. Dunno what else would be useful to help diagnose or disprove this, so feel free to reply directly to me. Regards, Aaron -- Aaron Turner https://synfin.net/ My father once told me that respect for the truth comes close to being the basis for all morality. "Something cannot emerge from nothing," he said. This is profound thinking if you understand how unstable "the truth" can be. -- Frank Herbert, Dune From Jason at zx2c4.com Fri Apr 22 00:02:21 2022 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 22 Apr 2022 02:02:21 +0200 Subject: [PATCH] WireGuard: restrict packet handling to non-isolated CPUs. In-Reply-To: <20220405212129.2270-1-cf.natali@gmail.com> References: <20220405212129.2270-1-cf.natali@gmail.com> Message-ID: netdev@ - Original thread is at https://lore.kernel.org/wireguard/20220405212129.2270-1-cf.natali at gmail.com/ Hi Charles-Fran?ois, On Tue, Apr 05, 2022 at 10:21:29PM +0100, Charles-Francois Natali wrote: > WireGuard currently uses round-robin to dispatch the handling of > packets, handling them on all online CPUs, including isolated ones > (isolcpus). > > This is unfortunate because it causes significant latency on isolated > CPUs - see e.g. below over 240 usec: > > kworker/47:1-2373323 [047] 243644.756405: funcgraph_entry: | > process_one_work() { kworker/47:1-2373323 [047] 243644.756406: > funcgraph_entry: | wg_packet_decrypt_worker() { [...] > kworker/47:1-2373323 [047] 243644.756647: funcgraph_exit: 0.591 us | } > kworker/47:1-2373323 [047] 243644.756647: funcgraph_exit: ! 242.655 us > | } > > Instead, restrict to non-isolated CPUs. Huh, interesting... I haven't seen this feature before. What's the intended use case? To never run _anything_ on those cores except processes you choose? To run some things but not intensive things? Is it sort of a RT-lite? I took a look in padata/pcrypt and it doesn't look like they're examining the housekeeping mask at all. Grepping for housekeeping_cpumask doesn't appear to show many results in things like workqueues, but rather in core scheduling stuff. So I'm not quite sure what to make of this patch. I suspect the thing to do might be to patch both wireguard and padata, and send a patch series to me, the padata people, and netdev at vger.kernel.org, and we can all hash this out together. Regarding your patch, is there a way to make that a bit more succinct, without introducing all of those helper functions? It seems awfully verbose for something that seems like a matter of replacing the online mask with the housekeeping mask. Jason From stephen at networkplumber.org Fri Apr 22 00:40:07 2022 From: stephen at networkplumber.org (Stephen Hemminger) Date: Thu, 21 Apr 2022 17:40:07 -0700 Subject: [PATCH] WireGuard: restrict packet handling to non-isolated CPUs. In-Reply-To: References: <20220405212129.2270-1-cf.natali@gmail.com> Message-ID: <20220421174007.0c210496@hermes.local> On Fri, 22 Apr 2022 02:02:21 +0200 "Jason A. Donenfeld" wrote: > netdev@ - Original thread is at > https://lore.kernel.org/wireguard/20220405212129.2270-1-cf.natali at gmail.com/ > > Hi Charles-Fran?ois, > > On Tue, Apr 05, 2022 at 10:21:29PM +0100, Charles-Francois Natali wrote: > > WireGuard currently uses round-robin to dispatch the handling of > > packets, handling them on all online CPUs, including isolated ones > > (isolcpus). > > > > This is unfortunate because it causes significant latency on isolated > > CPUs - see e.g. below over 240 usec: > > > > kworker/47:1-2373323 [047] 243644.756405: funcgraph_entry: | > > process_one_work() { kworker/47:1-2373323 [047] 243644.756406: > > funcgraph_entry: | wg_packet_decrypt_worker() { [...] > > kworker/47:1-2373323 [047] 243644.756647: funcgraph_exit: 0.591 us | } > > kworker/47:1-2373323 [047] 243644.756647: funcgraph_exit: ! 242.655 us > > | } > > > > Instead, restrict to non-isolated CPUs. > > Huh, interesting... I haven't seen this feature before. What's the > intended use case? To never run _anything_ on those cores except > processes you choose? To run some things but not intensive things? Is it > sort of a RT-lite? > > I took a look in padata/pcrypt and it doesn't look like they're > examining the housekeeping mask at all. Grepping for > housekeeping_cpumask doesn't appear to show many results in things like > workqueues, but rather in core scheduling stuff. So I'm not quite sure > what to make of this patch. > > I suspect the thing to do might be to patch both wireguard and padata, > and send a patch series to me, the padata people, and > netdev at vger.kernel.org, and we can all hash this out together. > > Regarding your patch, is there a way to make that a bit more succinct, > without introducing all of those helper functions? It seems awfully > verbose for something that seems like a matter of replacing the online > mask with the housekeeping mask. > > Jason Applications like DPDK that do polling often use isolcpus or cgroups to keep unwanted rabble off of their cpus. Having wireguard use those cpus seems bad. From ml-wireguard at oern.de Fri Apr 22 06:16:49 2022 From: ml-wireguard at oern.de (=?UTF-8?Q?Bj=c3=b6rn_Fries?=) Date: Fri, 22 Apr 2022 08:16:49 +0200 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> Message-ID: Hello, Am 18.04.22 um 04:12 schrieb Nohk Two: > This > server allows the clients to access my LAN (e.g. 192.168.87.0/24) and [..] > But when the phones connect to the Wi-Fi of my home's router, the DHCP > assigns the IP addresses as 192.168.87.0/24, it's my LAN, to the phones. [...] > Or do you have better ideas ? the way I solve this is that I use a slightly larger /23-subnet in the AllowedIPs=192.168.87.0/23 and when I get a local IP inside 192.168.87.0/24 at home, the kernel automatically uses the more specific route. From tech at tootai.net Fri Apr 22 07:13:44 2022 From: tech at tootai.net (Daniel) Date: Fri, 22 Apr 2022 09:13:44 +0200 Subject: Choosing local IP address In-Reply-To: <91765b65-5daa-c699-4a72-b59b0f6f9ebb@rail.eu.org> References: <91765b65-5daa-c699-4a72-b59b0f6f9ebb@rail.eu.org> Message-ID: Hi Le 26/03/2022 ? 21:27, Erwan David a ?crit?: > Hello > > I have a wireguard setup between my home router (and the home network > behind) and a distant FreeBSD servers with several jails. > > I use IPv6 fir transport, but I have a routing problem because whan at > home I need to ssh to the server, and if I use for endpoint address > (on the home router) the main IPv6 address it ends up with a traffic > half out of the tunnel (from home to server), and half in the tunnel > (from server to home). > > > So I chose to add an IPv6 address to the server, route it outside the > tunnel and use it only for the tunnel. But I cannot specify to > wireguard on the server to use this address, thus I get packets from > the main address, my router changes the endpoint address and tunnel > does not work. > > How can I say to wireguard which IP address to use when sending ths > encrypted packets to the endpoint ? Not sure I understand your problem but you can't use the ip address used to mount the tunnel to access the other end. You have to give an ipv6 ULA address to each endpoint. In your case, this should be GUA Home <> GUA FreeBSD to mount the tunnel. To access the other end in ipv6, give an ULA address to each wg and you're done. Also be sure that you put the right address in your config file -- Daniel From wireguard at qupfer.de Fri Apr 22 09:29:10 2022 From: wireguard at qupfer.de (wireguard at qupfer.de) Date: Fri, 22 Apr 2022 11:29:10 +0200 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: <77422@imapsync> References: <77422@imapsync> Message-ID: <34a3aa4f-76b6-9fbe-93ec-01cee228b382@qupfer.de> On 18.04.22 04:12, Nohk Two wrote: > ?I guess there are something conflict because the vanilla IP network > and the allowed IP network are the same. Thats right, but you can simply use other IPs for your WG clients (192.168.187.0/24 or 172.16.0.0/24) From ml-wireguard at oern.de Fri Apr 22 09:51:17 2022 From: ml-wireguard at oern.de (=?UTF-8?Q?Bj=c3=b6rn_Fries?=) Date: Fri, 22 Apr 2022 11:51:17 +0200 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> Message-ID: <94ddb2e7-9181-1a38-1b35-3e1a9766846e@oern.de> Am 22.04.22 um 08:16 schrieb Bj?rn Fries: > the way I solve this is that I use a slightly larger /23-subnet in the > AllowedIPs=192.168.87.0/23 > > and when I get a local IP inside 192.168.87.0/24 at home, the kernel > automatically uses the more specific route. an example: my laptop e.g. has Address = 172.22.247.58/32 PrivateKey = xxx [Peer] PublicKey = xxx AllowedIPs = 172.22.144.1/32, 192.168.0.0/23 Endpoint = myhomeIP:51820 PersistentKeepalive = 25 172.22.144.1/32 is the wireguard-IP of my wireguard-server at home. This way I can reach for example my printer at 192.168.0.10 even if I am on the move, because my wireguard server is installed on my router at home (Unifi USG-3P). The printer sends it packets for 172.22.247.58 simply to its default gateway, which is my router/wg-server, that forwards it over wireguard. When I'm in my network at home, my laptop gets the IP 192.168.1.72/24 and automatically talks to the other devices in the LAN without taking the wireguard route, because the subnet is more specific. From nohktwo at gmail.com Fri Apr 22 11:05:40 2022 From: nohktwo at gmail.com (Nohk Two) Date: Fri, 22 Apr 2022 19:05:40 +0800 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> Message-ID: <1b8b8a8d-0805-2b88-4fbb-f0a05cb2d0d0@gmail.com> On 2022/4/22 14:16, Bj?rn Fries wrote: > Hello, > > Am 18.04.22 um 04:12 schrieb Nohk Two: >> This server allows the clients to access my LAN (e.g. 192.168.87.0/24) >> and > [..] >> But when the phones connect to the Wi-Fi of my home's router, the DHCP >> assigns the IP addresses as 192.168.87.0/24, it's my LAN, to the phones. > [...] >> Or do you have better ideas ? > > the way I solve this is that I use a slightly larger /23-subnet in the > AllowedIPs=192.168.87.0/23 > > and when I get a local IP inside 192.168.87.0/24 at home, the kernel > automatically uses the more specific route. I think I know your point. And since my network is 192.168.87.0/24, I have to use 192.168.86.0/23 (not 192.168.87.0/23) in the AllowedIPs. Because "87" is an odd number and it's "1000 0111" in binary However, it failed in my Android phone. There is no internet accessing as usual. I didn't try this in iPhone because Eugenio Tampieri told me that Wireguard for iOS has the feature I required (and worked nicely) but not Android. Maybe I have to adjust my LAN's network to even number to make /24 enlarge to /23 happy. Thank you very much. From nohktwo at gmail.com Fri Apr 22 12:08:35 2022 From: nohktwo at gmail.com (Nohk Two) Date: Fri, 22 Apr 2022 20:08:35 +0800 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: <34a3aa4f-76b6-9fbe-93ec-01cee228b382@qupfer.de> References: <77422@imapsync> <34a3aa4f-76b6-9fbe-93ec-01cee228b382@qupfer.de> Message-ID: On 2022/4/22 17:29, wireguard at qupfer.de wrote: > > On 18.04.22 04:12, Nohk Two wrote: >> ?I guess there are something conflict because the vanilla IP network >> and the allowed IP network are the same. > > Thats right, but you can simply use other IPs for your WG clients > (192.168.187.0/24 or 172.16.0.0/24) > Hello, I'm not sure if I understand your idea correctly. It's not easy to configure my router's DHCP server to assign specific IP addresses (192.168.187.0/24 or 172.16.0.0/24) to the specific phones which connect to my LAN. Even I did it eventually, the phones can't access to my LAN when the wireguard is turned off because "192.168.187.0/24 or 172.16.0.0/24" can't reach to my LAN (i.e. 192.168.87.0/24). By the way, the WG tunnel interface's IP address (e.g. 192.168.19.0/24) is already different from my LAN's (i.e. 192.168.87.0/24). Regards :) From nohktwo at gmail.com Fri Apr 22 13:00:32 2022 From: nohktwo at gmail.com (Nohk Two) Date: Fri, 22 Apr 2022 21:00:32 +0800 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: <94ddb2e7-9181-1a38-1b35-3e1a9766846e@oern.de> References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> <94ddb2e7-9181-1a38-1b35-3e1a9766846e@oern.de> Message-ID: On 2022/4/22 17:51, Bj?rn Fries wrote: > Am 22.04.22 um 08:16 schrieb Bj?rn Fries: >> the way I solve this is that I use a slightly larger /23-subnet in the >> AllowedIPs=192.168.87.0/23 >> >> and when I get a local IP inside 192.168.87.0/24 at home, the kernel >> automatically uses the more specific route. > > an example: > my laptop e.g. has > > Address = 172.22.247.58/32 > PrivateKey = xxx > > [Peer] > PublicKey = xxx > AllowedIPs = 172.22.144.1/32, 192.168.0.0/23 > Endpoint =? myhomeIP:51820 > PersistentKeepalive = 25 > > 172.22.144.1/32 is the wireguard-IP of my wireguard-server at home. > > This way I can reach for example my printer at 192.168.0.10 even if I am > on the move, because my wireguard server is installed on my router at > home (Unifi USG-3P). > The printer sends it packets for 172.22.247.58 simply to its default > gateway, which is my router/wg-server, that forwards it over wireguard. > > When I'm in my network at home, my laptop gets the IP 192.168.1.72/24 > and automatically talks to the other devices in the LAN without taking > the wireguard route, because the subnet is more specific. I referred to your example and the Android phone is now: [Interface] Address = 192.168.19.30/32 DNS = 192.168.87.1, 192.168.87.2 PrivateKey = xxx [Peer] PublicKey = xxx AllowedIPs = 192.168.19.1/32, 192.168.86.0/23 Endpoint = myhomeIP:4999 PresharedKey = xxx 192.168.19.1/32 is my wireguard-IP address of my wireguard-server at home. It work nicely if the Android phone is on 4G network. But it still failed when I connect to my LAN's Wi-Fi (no internet accessing and no LAN accessing). The phone got the LAN IP address 192.168.87.11/24 from the DHCP server. Maybe the routing implementation in Android doesn't fit this solution. Anyway, thank you very much. :) From ml-wireguard at oern.de Fri Apr 22 13:40:56 2022 From: ml-wireguard at oern.de (=?UTF-8?Q?Bj=c3=b6rn_Fries?=) Date: Fri, 22 Apr 2022 15:40:56 +0200 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: <1b8b8a8d-0805-2b88-4fbb-f0a05cb2d0d0@gmail.com> References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> <1b8b8a8d-0805-2b88-4fbb-f0a05cb2d0d0@gmail.com> Message-ID: <7b684ba4-60d8-2189-7aac-41804a02da99@oern.de> Am 22.04.22 um 13:05 schrieb Nohk Two: > However, it failed in my Android phone. I don't use wireguard on my phone on the moment, but perhaps there was a difference whether you use the (non-root) wireguard-go implementation or the kernel module on android. I guess I used the kernel module as I nearly weekly try new custom roms on my phone. From nohktwo at gmail.com Fri Apr 22 15:55:04 2022 From: nohktwo at gmail.com (Nohk Two) Date: Fri, 22 Apr 2022 23:55:04 +0800 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: <7b684ba4-60d8-2189-7aac-41804a02da99@oern.de> References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> <1b8b8a8d-0805-2b88-4fbb-f0a05cb2d0d0@gmail.com> <7b684ba4-60d8-2189-7aac-41804a02da99@oern.de> Message-ID: <256303f0-d167-3677-67c6-721a195129fa@gmail.com> On 2022/4/22 21:40, Bj?rn Fries wrote: > > > Am 22.04.22 um 13:05 schrieb Nohk Two: >> However, it failed in my Android phone. > I don't use wireguard on my phone on the moment, but perhaps there was a > difference whether you use the (non-root) wireguard-go implementation or > the kernel module on android. > I guess I used the kernel module as I nearly weekly try new custom roms > on my phone. I just checked my Wireguard for Android App, the settings page shows: WireGuard for Android v1.0.20211029 Go userspace backend eb6302c So my wireguard on my Android phone is the non-root wireguard-go implementation. So said that I don't use custom ROMs, I always use official ROMs. At least I still can turn off the wireguard manually. :) From simon at rozman.si Fri Apr 22 16:16:05 2022 From: simon at rozman.si (Simon Rozman) Date: Fri, 22 Apr 2022 16:16:05 +0000 Subject: Wireguard Windows Client questions In-Reply-To: <004a01d846c2$896fe0c0$9c4fa240$@comcast.net> References: <004a01d846c2$896fe0c0$9c4fa240$@comcast.net> Message-ID: > 1. The documentation implies that if I executed the following command > from a command line "wireguard.exe" that it will start the Manager > Service and show the UI. It then states that calling wireguard.exe > /installmanagerservice is suitable for silent installation but what I > find is that the Management GUI is still activated and shown on the > desktop. > Is there anyway to start the service without the GUI window appearing? > And is there anyway to prevent the UI in the system tray from being > installed? Try wireguard.exe /installtunnelservice mytunnel.conf and wireguard.exe /uninstalltunnelservice mytunnel.conf. > 2. If for any reason the Wireguard peer is not reachable then the > Handshake does not complete. When using the GUI the tunnel is shows > Active but it is the tunnelservice that is active not the connection. Is > there a way to limit the number of handshake retries before giving up on > trying to connect? WireGuard is connection-less. Only after there is a packet for a peer, it'll perform handshake with the peer and sent the packet to it. See it as on-demand connection. Now, if you insist on verifying if the connection is possible over the VPN tunnel, send a ping thru the tunnel and see if the handshake occurs and succeeds. > 3. From time to time the endpoint address of the peer system may have > changed (I do not use a dynamic DNS service) so when trying to connect I > hit the problem described in 2 above. I know what the new endpoint > address is and can set it dynamically using the wg set command and the > connection is then made. I would like to be able to programmatically > save this change without having to manually edit the client config > files. I tried using wg syncconf but get a permissions error because of > the properties around the dpapi config files. > Is there an alternative way to doing this short of deleting the existing > dpapi file and adding a new .conf file and have the manager service > encrypt it but that approach means I need to keep the private key in the > clear somewhere in order to create the new conf file.\ Jason suggested me to add a Scheduled Task to call wg.exe set mytunnel peer pubkey endpoint 1.2.3.4:11111 on a few minute basis. It works like a charm when roaming back and forth between local and remote networks. It's way more efficient than deactivating the tunnel, updating config and reactivating the tunnel. > 4. There are 2 option listed under wireguard command line options namely > /managerservice and /tunnelservice CONFIG_PATH - can someone tell me > what they are supposed to do every time I try running one of them I get > an error popup that says - The service process could not connect to the > service controller.wireguard Those options are to be used by Windows SCM when wireguard.exe runs as a service. If you are familiar with programming, you might want to take a look into the embeddable-dll-service folder in the wireguard-windows repo. Regards, Simon From simon at rozman.si Fri Apr 22 16:25:37 2022 From: simon at rozman.si (Simon Rozman) Date: Fri, 22 Apr 2022 16:25:37 +0000 Subject: Wintun on Windows 11 In-Reply-To: <367df062-5c7c-2916-db4d-afdf6c7d92db@cea.fr> References: <367df062-5c7c-2916-db4d-afdf6c7d92db@cea.fr> Message-ID: <0606b759a4ac40e2b3b791c4761d0d40@rozman.si> > The README states that Wintun "is a layer 3 TUN driver for Windows 7, 8, > 8.1, and 10": > https://git.zx2c4.com/wintun/tree/README.md#n4 > > You should add Windows 11 to the list. Thanks. Added. Regards, Simon From dadima at gmail.com Fri Apr 22 13:36:23 2022 From: dadima at gmail.com (Jason Grant) Date: Fri, 22 Apr 2022 08:36:23 -0500 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> Message-ID: <148B89DC-E709-41D2-B942-4FD63558EEDC@gmail.com> On 17 Apr 2022, at 21:12, Nohk Two wrote: > So, I have this idea that if it is possible to configure the Wireguard > app to turn off or disable automatically when the network is > established on specific Wi-Fi SSIDs ? The MacOS WireGuard client has exactly this feature. You can enable/disable on-demand access for particular SSIDs, and it?s very useful for a situation where you?re moving your device around, between home and office say. Any timetable for adding this feature to other platforms, like Windows or Android? From khaberz at gmail.com Fri Apr 22 18:23:07 2022 From: khaberz at gmail.com (Kai Haberzettl) Date: Fri, 22 Apr 2022 20:23:07 +0200 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> Message-ID: On Fri, Apr 22, 2022 at 2:26 AM Nohk Two wrote: > [...] > So, I have this idea that if it is possible to configure the Wireguard > app to turn off or disable automatically when the network is established > on specific Wi-Fi SSIDs ? > > Or do you have better ideas ? As a workaround, you can achieve what you want with tasker. From cf.natali at gmail.com Fri Apr 22 22:23:01 2022 From: cf.natali at gmail.com (=?UTF-8?Q?Charles=2DFran=C3=A7ois_Natali?=) Date: Fri, 22 Apr 2022 23:23:01 +0100 Subject: [PATCH] WireGuard: restrict packet handling to non-isolated CPUs. In-Reply-To: References: <20220405212129.2270-1-cf.natali@gmail.com> Message-ID: Hi, On Fri, 22 Apr 2022 at 01:02, Jason A. Donenfeld wrote: > > netdev@ - Original thread is at > https://lore.kernel.org/wireguard/20220405212129.2270-1-cf.natali at gmail.com/ > > Hi Charles-Fran?ois, > > On Tue, Apr 05, 2022 at 10:21:29PM +0100, Charles-Francois Natali wrote: > > WireGuard currently uses round-robin to dispatch the handling of > > packets, handling them on all online CPUs, including isolated ones > > (isolcpus). > > > > This is unfortunate because it causes significant latency on isolated > > CPUs - see e.g. below over 240 usec: > > > > kworker/47:1-2373323 [047] 243644.756405: funcgraph_entry: | > > process_one_work() { kworker/47:1-2373323 [047] 243644.756406: > > funcgraph_entry: | wg_packet_decrypt_worker() { [...] > > kworker/47:1-2373323 [047] 243644.756647: funcgraph_exit: 0.591 us | } > > kworker/47:1-2373323 [047] 243644.756647: funcgraph_exit: ! 242.655 us > > | } > > > > Instead, restrict to non-isolated CPUs. > > Huh, interesting... I haven't seen this feature before. What's the > intended use case? To never run _anything_ on those cores except > processes you choose? To run some things but not intensive things? Is it > sort of a RT-lite? Yes, the idea is to not run anything on those cores: no user tasks, no unbound workqueues, etc. Typically one would also set IRQ affinity etc to avoid those cores, to avoid (soft)IRQS which cause significant latency as well. This series by Frederic Weisbecker is a good introduction: https://www.suse.com/c/cpu-isolation-introduction-part-1/ The idea is to achieve low latency and jitter. With a reasonably tuned kernel one can reach around 10usec latency - however whenever we start using wireguard, we can see the bound workqueues used for round-robin dispatch cause up to 1ms stalls, which is just not acceptable for us. Currently our only option is to either patch the wireguard code, or stop using it, which would be a shame :). > I took a look in padata/pcrypt and it doesn't look like they're > examining the housekeeping mask at all. Grepping for > housekeeping_cpumask doesn't appear to show many results in things like > workqueues, but rather in core scheduling stuff. So I'm not quite sure > what to make of this patch. Thanks, I didn't know about padata, but after skimming through the code it does seem that it would suffer from the same issue. > I suspect the thing to do might be to patch both wireguard and padata, > and send a patch series to me, the padata people, and > netdev at vger.kernel.org, and we can all hash this out together. Sure, I'll try to have a look at the padata code and write something up. > Regarding your patch, is there a way to make that a bit more succinct, > without introducing all of those helper functions? It seems awfully > verbose for something that seems like a matter of replacing the online > mask with the housekeeping mask. Indeed, I wasn't really happy about that. The reason I've written those helper functions is that the housekeeping mask includes possible CPUs (cpu_possible_mask), so unfortunately it's not just a matter of e.g. replacing cpu_online_mask with housekeeping_cpumask(HK_FLAG_DOMAIN), we have to perform an AND whenever we compute the weight, find the next CPU in the mask etc. And I'd rather have the operations and mask in a single location instead of scattered throughout the code, to make it easier to understand and maintain. Happy to change to something more inline though, or open to suggestions. Cheers, Charles > > Jason From Jason at zx2c4.com Sat Apr 23 01:08:04 2022 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sat, 23 Apr 2022 03:08:04 +0200 Subject: [PATCH] WireGuard: restrict packet handling to non-isolated CPUs. In-Reply-To: References: <20220405212129.2270-1-cf.natali@gmail.com> Message-ID: Hi Charles, On Fri, Apr 22, 2022 at 11:23:01PM +0100, Charles-Fran?ois Natali wrote: > > Regarding your patch, is there a way to make that a bit more succinct, > > without introducing all of those helper functions? It seems awfully > > verbose for something that seems like a matter of replacing the online > > mask with the housekeeping mask. > > Indeed, I wasn't really happy about that. > The reason I've written those helper functions is that the housekeeping mask > includes possible CPUs (cpu_possible_mask), so unfortunately it's not just a > matter of e.g. replacing cpu_online_mask with > housekeeping_cpumask(HK_FLAG_DOMAIN), we have to perform an AND > whenever we compute the weight, find the next CPU in the mask etc. > > And I'd rather have the operations and mask in a single location instead of > scattered throughout the code, to make it easier to understand and maintain. > > Happy to change to something more inline though, or open to suggestions. Probably more inlined, yea. A simpler version of your patch would probably be something like this, right? diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h index 583adb37ee1e..b3117cdd647d 100644 --- a/drivers/net/wireguard/queueing.h +++ b/drivers/net/wireguard/queueing.h @@ -112,6 +112,8 @@ static inline int wg_cpumask_choose_online(int *stored_cpu, unsigned int id) cpu = cpumask_first(cpu_online_mask); for (i = 0; i < cpu_index; ++i) cpu = cpumask_next(cpu, cpu_online_mask); + while (!housekeeping_test_cpu(cpu, HK_???)) + cpu = cpumask_next(cpu, cpu_online_mask); *stored_cpu = cpu; } return cpu; @@ -128,7 +130,7 @@ static inline int wg_cpumask_next_online(int *next) { int cpu = *next; - while (unlikely(!cpumask_test_cpu(cpu, cpu_online_mask))) + while (unlikely(!cpumask_test_cpu(cpu, cpu_online_mask) && !housekeeping_test_cpu(cpu, HK_???))) cpu = cpumask_next(cpu, cpu_online_mask) % nr_cpumask_bits; *next = cpumask_next(cpu, cpu_online_mask) % nr_cpumask_bits; return cpu; However, from looking at kernel/sched/isolation.c a bit, I noticed that indeed you're right that most of these functions (save one) are based on cpu_possible_mask rather than cpu_online_mask. This is frustrating because the code makes smart use of static branches to remain quick, but ANDing housekeeping_cpumask() with cpu_online_mask would, in the fast path, wind up ANDing cpu_online_mask with cpu_possible_mask, which is silly and pointless. That makes me suspect that maybe the best approach would be adding a relevant helper to kernel/sched/isolation.c, so that the helper can then do the `if (static_branch_unlikely(&housekeeping_overridden))` stuff internally. Or maybe you'll do some measurements and decide that just [ab]using housekeeping_test_cpu() like above is actually optimal? Not really sure myself. Anyway, I'll keep an eye out for your joint wireguard/padata series. Be sure to CC the people who wrote the isolation & housekeeping code, as they likely have opinions about this stuff (and certainly know more than me about it). Jason From nohktwo at gmail.com Sat Apr 23 02:01:28 2022 From: nohktwo at gmail.com (Nohk Two) Date: Sat, 23 Apr 2022 10:01:28 +0800 Subject: Is it possible to disable wireguard on specific Wi-Fi ? In-Reply-To: References: <84b2749c-4a9d-b58e-0659-09ee9c70c67c@gmail.com> Message-ID: <1dd6c632-0aa3-fffe-78fe-cfb61c22028e@gmail.com> On 2022/4/23 02:23, Kai Haberzettl wrote: > On Fri, Apr 22, 2022 at 2:26 AM Nohk Two wrote: >> > [...] >> So, I have this idea that if it is possible to configure the Wireguard >> app to turn off or disable automatically when the network is established >> on specific Wi-Fi SSIDs ? >> >> Or do you have better ideas ? > > As a workaround, you can achieve what you want with tasker. Indeed, this "tasker" app might work. Though it's some kind of overkill. I will consider this workaround on the Android phone when there are no other solutions. Thank you very much. From steved at redhat.com Sun Apr 24 18:16:24 2022 From: steved at redhat.com (Steve Dickson) Date: Sun, 24 Apr 2022 14:16:24 -0400 Subject: wireguard.ko on RHEL8 Message-ID: <22218021-270c-8ac9-c214-76ae4e1c1263@redhat.com> Hello, Trying to install wireguard.ko on a RHEL8 vm (4.18.0-348.el8.x86_64) and I'm getting wireguard: module verification failed: signature and/or required key missing - tainting kernel The entire error: http://pastebin.test.redhat.com/1046896 is there anything at can be done about that? I'm new to wireguard and I'm pretty impress... It came up in both Fedora rawhide and an unreleased verson of RHEL9... We are trying to used it as our network in a community wide virtual NFS testing event called Bakeathon [1] Again I'm new to wireguard but not to kernels ;-) So if you could throw something at me to help me get over this bum... It would be appreciated! Note: I am not member of this list so please reply to be directly. tia, steved. [1] http://www.nfsv4bat.org/Events/2022/Apr/BAT/index.html From joe at solidadmin.com Sun Apr 24 20:03:37 2022 From: joe at solidadmin.com (Joe Doss) Date: Sun, 24 Apr 2022 15:03:37 -0500 Subject: wireguard.ko on RHEL8 In-Reply-To: <22218021-270c-8ac9-c214-76ae4e1c1263@redhat.com> References: <22218021-270c-8ac9-c214-76ae4e1c1263@redhat.com> Message-ID: Hey Steve, On 4/24/22 1:16 PM, Steve Dickson wrote: > > Trying to install wireguard.ko on a RHEL8 vm (4.18.0-348.el8.x86_64) > and I'm getting > > ?? wireguard: module verification failed: signature and/or required key > missing - tainting kernel > > The entire error: > http://pastebin.test.redhat.com/1046896 > > is there anything at can be done about that? > > I'm new to wireguard and I'm pretty impress... > It came up in both Fedora rawhide and an > unreleased verson of RHEL9... > > We are trying to used it as our network in > a community wide virtual NFS testing event > called Bakeathon [1] > > Again I'm new to wireguard but not to kernels ;-) > So if you could throw something at me to > help me get over this bum... It would be appreciated! > > Note: I am not member of this list so please > reply to be directly. You have secure boot enabled, so you need to generate a MOK key pair, manually sign your wireguard.ko, and enroll your MOK cert or disable secure boot. I use this script [1] to sign my NVIDIA drivers on my workstation after they are built via akmod. Hope this helps! Joe [1]: https://gist.github.com/jdoss/495e814ef4ef599e480c31d4843eb6c0 -- Joe Doss joe at solidadmin.com From andreas.weigel at posteo.de Fri Apr 22 17:45:05 2022 From: andreas.weigel at posteo.de (Andreas Weigel) Date: Fri, 22 Apr 2022 17:45:05 +0000 Subject: [PATCH 0/1] wg syncconf not clearing PresharedKey/PersistentKeepalive Message-ID: <20220422174506.22299-1-andreas.weigel@posteo.de> Hi, I noticed that wg syncconf does not actually clear PresharedKey and PersistentKeepalive values if those are not set in the file but set in the running config. The proposed patch changes that to always clear those if they are not set in the configuration file, which imho is the correct behavior. Andreas Andreas Weigel (1): wg syncconf: explicitly reset PresharedKey/PersistentKeepalive src/setconf.c | 8 ++++++++ 1 file changed, 8 insertions(+) -- 2.25.1 From andreas.weigel at posteo.de Fri Apr 22 17:45:06 2022 From: andreas.weigel at posteo.de (Andreas Weigel) Date: Fri, 22 Apr 2022 17:45:06 +0000 Subject: [PATCH 1/1] wg syncconf: explicitly reset PresharedKey/PersistentKeepalive In-Reply-To: <20220422174506.22299-1-andreas.weigel@posteo.de> References: <20220422174506.22299-1-andreas.weigel@posteo.de> Message-ID: <20220422174506.22299-2-andreas.weigel@posteo.de> make wg syncconf correctly clear a preshared key or keepalive in case the file config does not define those; currently syncconf does not change these settings at all if runtime has them set but file does not --- src/setconf.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/setconf.c b/src/setconf.c index bfd0a3a..8661a92 100644 --- a/src/setconf.c +++ b/src/setconf.c @@ -63,6 +63,14 @@ static bool sync_conf(struct wgdevice *file) } for_each_wgpeer(file, peer) { + if (!(peer->flags & WGPEER_HAS_PRESHARED_KEY)) { + memset(peer->preshared_key, 0, WG_KEY_LEN); + peer->flags |= WGPEER_HAS_PRESHARED_KEY; + } + if (!(peer->flags & WGPEER_HAS_PERSISTENT_KEEPALIVE_INTERVAL)) { + peer->persistent_keepalive_interval = 0; + peer->flags |= WGPEER_HAS_PERSISTENT_KEEPALIVE_INTERVAL; + } pubkeys[i].pubkey = peer->public_key; pubkeys[i].from_file = true; ++i; -- 2.25.1 From zer0flash at anterias.io Fri Apr 22 20:21:45 2022 From: zer0flash at anterias.io (zer0flash at anterias.io) Date: Fri, 22 Apr 2022 22:21:45 +0200 Subject: Using WireGuard on Windows as non-admin - proper solution? In-Reply-To: References: <8bf9e364f87bd0018dabca03dcc8c19b@mail.gmail.com> <3b4f9ec2-2f50-25c9-0e27-7ca0d2f16943@maidenheadbridge.com> Message-ID: <4b222049-3ea1-356b-d50c-6b6533fb9eb1@anterias.io> Hi, On Sun, Nov 29, 2020 at 9:59 PM Jason A. Donenfeld wrote: > On Sun, Nov 29, 2020 at 8:44 PM Phillip McMahon > wrote: >> Won't drag this already long and confusing thread out. Not challenging >> the current implementation, just the notion that any other suggestion >> is a dead end and the topic is closed. > > Alright. Well, if you do think of good reasons why NCO is not a good > match for unpriv'd WireGuard control, please let me know. The whole > basis of going that route is the apparent intuition that these two > types of things, network modification and tunnel up/down, are one and > the same. But if you have in mind a way where the analogy breaks down, > that'd be very interesting to learn and would potentially be grounds > for changing course. We provision a lot of road warrior laptops, where users are not admins. They can of course use 5g, wifi or lan as required and have to be able to switch on/off the vpn tunnel. If working from our office for example, they do not need the vpn due to an existing site-to-site vpn connection. So they need to turn it off by themselves. That's why the feature makes a lot of sense in my humble opinition. However, any member of the local "Network Configuration Operators" group is not only able to to activate the WireGuard tunnel but also - disable any firewall rules - add new any firewall rules - disable the whole firewall by changing the default to allow all incoming - change ip address / dns settings on any interface I think that adding an otherwise unprivileged user to the NCO group just for activating a preconfigured vpn tunnel might pose security issues in other areas. > > Jason > Regards -- Fabian From royaza1998 at gmail.com Sun Apr 24 09:19:50 2022 From: royaza1998 at gmail.com (roy azachi) Date: Sun, 24 Apr 2022 12:19:50 +0300 Subject: [PATCH] Fix Wireguard-Apple Logger Memory Leak (Fix Wireguard-Apple Logger Memory Leak) Message-ID: Using "Instruments" tool shows every log message from the SystemExtension creates a persistent allocation. Although it seems there is no retain cycle, the allocated resources are not freed, which might be caused by the way the function is invoked using golang instead of the usual swift invocation freeing allocations with zero retain counter . Using the "autoreleasepool" seems to solve it. the call tree not freed: 12 WireGuardNetworkExtension runtime.asmcgocall.abi0 11 WireGuardNetworkExtension _cgo_f1100e4bfc6f_Cfunc_callLogger 10 WireGuardNetworkExtension callLogger 9 WireGuardNetworkExtension @objc closure #1 in WireGuardAdapter.setupLogHandler() /wireguard-apple/:0 8 WireGuardNetworkExtension closure #1 in WireGuardAdapter.setupLogHandler() /wireguard-apple/Sources/WireGuardKit/WireGuardAdapter.swift:299 7 libswiftCore.dylib specialized static String._fromUTF8Repairing(_:) 6 libswiftCore.dylib specialized static String._uncheckedFromUTF8(_:asciiPreScanResult:) 5 libswiftCore.dylib specialized static __StringStorage.create(initializingFrom:isASCII:) 4 libswiftCore.dylib _allocateStringStorage(codeUnitCapacity:) 3 libswiftCore.dylib _swift_allocObject_ 2 libswiftCore.dylib _swift_allocObject_ 1 libswiftCore.dylib swift_slowAlloc 0 libsystem_malloc.dylib _malloc_zone_malloc Signed-off-by: Roy Azachi --- Sources/WireGuardKit/WireGuardAdapter.swift | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Sources/WireGuardKit/WireGuardAdapter.swift b/Sources/WireGuardKit/WireGuardAdapter.swift index 4cb2e2e..3828951 100644 --- a/Sources/WireGuardKit/WireGuardAdapter.swift +++ b/Sources/WireGuardKit/WireGuardAdapter.swift @@ -295,11 +295,12 @@ public class WireGuardAdapter { let unretainedSelf = Unmanaged.fromOpaque(context) .takeUnretainedValue() + autoreleasepool { + let swiftString = String(cString: message).trimmingCharacters(in: .newlines) + let tunnelLogLevel = WireGuardLogLevel(rawValue: logLevel) ?? .verbose - let swiftString = String(cString: message).trimmingCharacters(in: .newlines) - let tunnelLogLevel = WireGuardLogLevel(rawValue: logLevel) ?? .verbose - - unretainedSelf.logHandler(tunnelLogLevel, swiftString) + unretainedSelf.logHandler(tunnelLogLevel, swiftString) + } } } -- 2.30.1 (Apple Git-130) From elul.natan at gmail.com Sun Apr 24 09:20:08 2022 From: elul.natan at gmail.com (Natan Elul) Date: Sun, 24 Apr 2022 12:20:08 +0300 Subject: [PATCH] [wireguard-go] Pool for endpoint objects Message-ID: Use sync.pool for endpoints to avoid memory allocations on each receive. When an endpoint is returned in bind linux, go allocates memory on the heap By using sync.pool, the allocations can be reused, and can dramatically be more efficient. This patch includes the changes for linux bind, and an optimization for SetEndpointFor packet, that will use the lock only if needed. Signed-off-by: Natan Elul --- conn/bind_linux.go | 58 +++++++++++++++++++++++++++++++-------- conn/bind_std.go | 15 ++++++++++ conn/bind_windows.go | 14 ++++++++++ conn/bindtest/bindtest.go | 11 ++++++++ conn/conn.go | 5 ++++ device/peer.go | 11 +++++++- device/pools.go | 1 + device/receive.go | 1 + 8 files changed, 103 insertions(+), 13 deletions(-) diff --git a/conn/bind_linux.go b/conn/bind_linux.go index f11f031..5630481 100644 --- a/conn/bind_linux.go +++ b/conn/bind_linux.go @@ -38,6 +38,24 @@ func (endpoint *LinuxSocketEndpoint) Src4() *ipv4Source { return endpoin func (endpoint *LinuxSocketEndpoint) Dst4() *unix.SockaddrInet4 { return endpoint.dst4() } func (endpoint *LinuxSocketEndpoint) IsV6() bool { return endpoint.isV6 } +func (endpoint *LinuxSocketEndpoint) IsEqual(ep Endpoint) bool { + // Protect from mutable sendmsg + endpoint.mu.Lock() + defer endpoint.mu.Unlock() + + linuxEp := ep.(*LinuxSocketEndpoint) + return endpoint.dst == linuxEp.dst && endpoint.src == linuxEp.src +} + +func (endpoint *LinuxSocketEndpoint) Copy() Endpoint { + return &LinuxSocketEndpoint{ + mu: sync.Mutex{}, + dst: endpoint.dst, + src: endpoint.src, + isV6: endpoint.isV6, + } +} + func (endpoint *LinuxSocketEndpoint) src4() *ipv4Source { return (*ipv4Source)(unsafe.Pointer(&endpoint.src[0])) } @@ -58,13 +76,28 @@ func (endpoint *LinuxSocketEndpoint) dst6() *unix.SockaddrInet6 { type LinuxSocketBind struct { // mu guards sock4 and sock6 and the associated fds. // As long as someone holds mu (read or write), the associated fds are valid. - mu sync.RWMutex - sock4 int - sock6 int + mu sync.RWMutex + sock4 int + sock6 int + epElementsPool sync.Pool +} + +func (bind *LinuxSocketBind) GetEndpoint() *LinuxSocketEndpoint { + return bind.epElementsPool.Get().(*LinuxSocketEndpoint) } -func NewLinuxSocketBind() Bind { return &LinuxSocketBind{sock4: -1, sock6: -1} } -func NewDefaultBind() Bind { return NewLinuxSocketBind() } +func (bind *LinuxSocketBind) PutEndpoint(endpoint Endpoint) { + bind.epElementsPool.Put(endpoint) +} + +func NewLinuxSocketBind() Bind { + return &LinuxSocketBind{sock4: -1, sock6: -1, + epElementsPool: sync.Pool{New: func() interface{} { + return new(LinuxSocketEndpoint) + }}} +} + +func NewDefaultBind() Bind { return NewLinuxSocketBind() } var ( _ Endpoint = (*LinuxSocketEndpoint)(nil) @@ -224,14 +257,14 @@ func (bind *LinuxSocketBind) Close() error { } func (bind *LinuxSocketBind) receiveIPv4(buf []byte) (int, Endpoint, error) { + end := bind.GetEndpoint() bind.mu.RLock() defer bind.mu.RUnlock() if bind.sock4 == -1 { return 0, nil, net.ErrClosed } - var end LinuxSocketEndpoint - n, err := receive4(bind.sock4, buf, &end) - return n, &end, err + n, err := receive4(bind.sock4, buf, end) + return n, end, err } func (bind *LinuxSocketBind) receiveIPv6(buf []byte) (int, Endpoint, error) { @@ -448,11 +481,12 @@ func send4(sock int, end *LinuxSocketEndpoint, buff []byte) error { // clear src and retry if err == unix.EINVAL { - end.ClearSrc() + // clear source writing to source ip that can collide with isEqual read. this is a rare execution code, so we will just + // create a copy and use it instead. (avoid write) + newEndpoint := end.Copy().(*LinuxSocketEndpoint) + newEndpoint.ClearSrc() cmsg.pktinfo = unix.Inet4Pktinfo{} - end.mu.Lock() - _, err = unix.SendmsgN(sock, buff, (*[unsafe.Sizeof(cmsg)]byte)(unsafe.Pointer(&cmsg))[:], end.dst4(), 0) - end.mu.Unlock() + _, err = unix.SendmsgN(sock, buff, (*[unsafe.Sizeof(cmsg)]byte)(unsafe.Pointer(&cmsg))[:], newEndpoint.dst4(), 0) } return err diff --git a/conn/bind_std.go b/conn/bind_std.go index e0f6cdd..4306f7f 100644 --- a/conn/bind_std.go +++ b/conn/bind_std.go @@ -27,8 +27,23 @@ type StdNetBind struct { func NewStdNetBind() Bind { return &StdNetBind{} } +func (bind *StdNetBind) PutEndpoint(endpoint Endpoint) { +} + type StdNetEndpoint netip.AddrPort +func (e *StdNetEndpoint) IsEqual(endpoint Endpoint) bool { + addrPort := (*netip.AddrPort)(e) + addrPortParam := (*netip.AddrPort)(endpoint.(*StdNetEndpoint)) + return addrPort.Port() == addrPortParam.Port() && addrPort.Addr().Compare(addrPortParam.Addr()) == 0 +} + +func (e *StdNetEndpoint) Copy() Endpoint { + addrPortString := (*netip.AddrPort)(e).String() + copyEndpoint, _ := netip.ParseAddrPort(addrPortString) + return (*StdNetEndpoint)(©Endpoint) +} + var ( _ Bind = (*StdNetBind)(nil) _ Endpoint = (*StdNetEndpoint)(nil) diff --git a/conn/bind_windows.go b/conn/bind_windows.go index 9268bc1..d0a1d66 100644 --- a/conn/bind_windows.go +++ b/conn/bind_windows.go @@ -77,6 +77,9 @@ type WinRingBind struct { isOpen uint32 } +func (bind *WinRingBind) PutEndpoint(endpoint Endpoint) { +} + func NewDefaultBind() Bind { return NewWinRingBind() } func NewWinRingBind() Bind { @@ -131,6 +134,17 @@ func (*WinRingBind) ParseEndpoint(s string) (Endpoint, error) { func (*WinRingEndpoint) ClearSrc() {} +func (e *WinRingEndpoint) IsEqual(endpoint Endpoint) bool { + winEndpoint := endpoint.(*WinRingEndpoint) + return winEndpoint.family == e.family && winEndpoint.data == e.data +} + +func (e *WinRingEndpoint) Copy() Endpoint { + return &WinRingEndpoint{ + family: e.family, + data: e.data, + } +} func (e *WinRingEndpoint) DstIP() netip.Addr { switch e.family { case windows.AF_INET: diff --git a/conn/bindtest/bindtest.go b/conn/bindtest/bindtest.go index b38cae6..a04ccc9 100644 --- a/conn/bindtest/bindtest.go +++ b/conn/bindtest/bindtest.go @@ -23,8 +23,19 @@ type ChannelBind struct { target4, target6 ChannelEndpoint } +func (c *ChannelBind) PutEndpoint(endpoint conn.Endpoint) { +} + type ChannelEndpoint uint16 +func (c ChannelEndpoint) IsEqual(endpoint conn.Endpoint) bool { + return c == endpoint.(ChannelEndpoint) +} + +func (c ChannelEndpoint) Copy() conn.Endpoint { + return c +} + var ( _ conn.Bind = (*ChannelBind)(nil) _ conn.Endpoint = (*ChannelEndpoint)(nil) diff --git a/conn/conn.go b/conn/conn.go index 5a93b2b..c772b25 100644 --- a/conn/conn.go +++ b/conn/conn.go @@ -43,6 +43,9 @@ type Bind interface { // ParseEndpoint creates a new endpoint from a string. ParseEndpoint(s string) (Endpoint, error) + + // PutEndpoint returns endpoint back to pool + PutEndpoint(endpoint Endpoint) } // BindSocketToInterface is implemented by Bind objects that support being @@ -70,6 +73,8 @@ type Endpoint interface { DstToBytes() []byte // used for mac2 cookie calculations DstIP() netip.Addr SrcIP() netip.Addr + IsEqual(endpoint Endpoint) bool + Copy() Endpoint } var ( diff --git a/device/peer.go b/device/peer.go index 5bd52df..eb1cc41 100644 --- a/device/peer.go +++ b/device/peer.go @@ -271,7 +271,16 @@ func (peer *Peer) SetEndpointFromPacket(endpoint conn.Endpoint) { if peer.disableRoaming { return } + + peer.RLock() + if peer.endpoint.IsEqual(endpoint) { + peer.RUnlock() + return + } + + peer.RUnlock() + peer.Lock() - peer.endpoint = endpoint + peer.endpoint = endpoint.Copy() peer.Unlock() } diff --git a/device/pools.go b/device/pools.go index f40477b..f861c51 100644 --- a/device/pools.go +++ b/device/pools.go @@ -70,6 +70,7 @@ func (device *Device) GetInboundElement() *QueueInboundElement { } func (device *Device) PutInboundElement(elem *QueueInboundElement) { + device.net.bind.PutEndpoint(elem.endpoint) elem.clearPointers() device.pool.inboundElements.Put(elem) } diff --git a/device/receive.go b/device/receive.go index cc34498..e6cebcd 100644 --- a/device/receive.go +++ b/device/receive.go @@ -390,6 +390,7 @@ func (device *Device) RoutineHandshake(id int) { peer.SendKeepalive() } skip: + device.net.bind.PutEndpoint(elem.endpoint) device.PutMessageBuffer(elem.buffer) } } -- 2.30.1 (Apple Git-130) From szymonn841 at gmail.com Mon Apr 25 07:46:18 2022 From: szymonn841 at gmail.com (Szymon Nowak) Date: Mon, 25 Apr 2022 09:46:18 +0200 Subject: Windows version two big problems Message-ID: I found two Wireguard problems under Windows and am looking for help First problem When you generate a key, its first character is ?\? or ?+? then the peer configuration does not work properly and you cannot connect to such configured client Exampe C:\Program Files\WireGuard>wg genpsk +RFmc+cEztZ/XcNquWvUJdNqlVfYWB3fM7bVCDaUOV4= [Peer] PublicKey = vruCee8G/DSwxotMHfhYQu8hcDEyi6uX4XEjT4FDxDc= PresharedKey = +RFmc+cEztZ/XcNquWvUJdNqlVfYWB3fM7bVCDaUOV4= All the peers below stop working Second problem When i add rule to VPN peer example C:\Program Files\WireGuard>wg set peer_server peer pExQ/CXgvHrq6kSO15H+PnCwDxENY7Mk3P7rPYv0F3Y= preshared-key client3_PresharedKey allowed-ips 10.0.0.4/32 Then i cant update config file C:\Program Files\WireGuard>wg setconf peer_server peer_server.conf Line unrecognized: `Address=10.0.0.1/24' Configuration parsing error Wg not supporte "Addres line" - I know , only wq-quick supoort this rule but wg-quick not exist on Windows platform . Every time I have to add a rule manually and restart the service, then I disconnect all clients From gamedev.pierre.grimme at gmail.com Wed Apr 27 18:50:58 2022 From: gamedev.pierre.grimme at gmail.com (Pierre Grimme) Date: Wed, 27 Apr 2022 20:50:58 +0200 Subject: Feature Request: Configurable Re-Resolving of DNS Endpoints Message-ID: [Situation] Using a Domain as Endpoint on your WG-Client to reach the server with a dynamic IP address breaks the connectivity when the server changes its public IP address. Wireguard only resolves domains once and uses from there on the resolved IP address. This is a huge problem in the private sector, where static IP addresses are not common. Even worse is the situation with Dual-Stack-Lite configurations, where your public IPv4 address is not reachable from outside. You have to use domains pointing to your current IPv6 address to get connection to your local network. The end user does not understand why the connection is not working anymore, especially on mobile devices. Also, a workaround with the re-resolve script is not possible due to lack of system file access and permissions. Private internet connections are force quitted every 24h. More often if something goes wrong. [Intention] There is an open-source project called netmaker which builds meshed networks with wireguard vpn connections. If you try to self-host this program on your private internet connection you need an endpoint address which is static. The need here is to input an address dynamically via a domain so you could always reach your server master. [Solution] The solution would be to re-resolve the endpoint address from time to time. The big benefit is that your endpoint IP could be dynamic. Your domain can point to a cname, a or aaaa record, which would enable people with a Dual-Stack-Lite internet connection a "stable" connection. Due to the concept of wireguard to be minimalistic it would be perfect, if the feature is off by default and only turned on when you enable it in wg-interface config. It would be great to have a configurable parameter e.g "dns-resolve-duration = 10 #in seconds" The solution should be usable with all available wireguard clients. From gamedev.pierre.grimme at gmail.com Thu Apr 28 05:55:48 2022 From: gamedev.pierre.grimme at gmail.com (Pierre Grimme) Date: Thu, 28 Apr 2022 07:55:48 +0200 Subject: Feature Request: Configurable Re-Resolving of DNS Endpoints In-Reply-To: References: Message-ID: Am Mi., 27. Apr. 2022 um 22:55 Uhr schrieb Omkhar Arasaratnam : > > Like this? > > https://github.com/WireGuard/wireguard-tools/blob/master/contrib/reresolve-dns/reresolve-dns.sh This script may be a good option for Linux Clients, but for Android devices or Chromebook not. The main point of this feature request is to provide an additional configurable parameter which implements nicely into wg.conf files. From steved at redhat.com Thu Apr 28 16:06:31 2022 From: steved at redhat.com (Steve Dickson) Date: Thu, 28 Apr 2022 12:06:31 -0400 Subject: wireguard.ko on RHEL8 In-Reply-To: References: <22218021-270c-8ac9-c214-76ae4e1c1263@redhat.com> Message-ID: Hey! My apologies on my delayed response... On 4/24/22 4:03 PM, Joe Doss wrote: > Hey Steve, > > On 4/24/22 1:16 PM, Steve Dickson wrote: >> >> Trying to install wireguard.ko on a RHEL8 vm (4.18.0-348.el8.x86_64) >> and I'm getting >> >> ??? wireguard: module verification failed: signature and/or required >> key missing - tainting kernel >> >> The entire error: >> http://pastebin.test.redhat.com/1046896 >> >> is there anything at can be done about that? >> >> I'm new to wireguard and I'm pretty impress... >> It came up in both Fedora rawhide and an >> unreleased verson of RHEL9... >> >> We are trying to used it as our network in >> a community wide virtual NFS testing event >> called Bakeathon [1] >> >> Again I'm new to wireguard but not to kernels ;-) >> So if you could throw something at me to >> help me get over this bum... It would be appreciated! >> >> Note: I am not member of this list so please >> reply to be directly. > > You have secure boot enabled, so you need to generate a MOK key pair, > manually sign your wireguard.ko, and enroll your MOK cert or disable > secure boot. > > I use this script [1] to sign my NVIDIA drivers on my workstation after > they are built via akmod. > > Hope this helps! > Joe > > [1]: https://gist.github.com/jdoss/495e814ef4ef599e480c31d4843eb6c0 > Thanks for the pointer... but I ended doing something different that worked very well... 1) I enabled the Fedora Infra Cloud repo which has the jdoss/wireguard repo dnf copr enable jdoss/wireguard 2) Then installed the wireguard-dkms and wireguard-tools packets which brought in the dkms command. dnf install wireguard-dkms wireguard-tools 3) Then I simply reboot and mdks compile the module and installed it... Very cool! Thanks again! steved. From jrickett at twopicode.com.au Tue Apr 26 11:20:01 2022 From: jrickett at twopicode.com.au (James Rickett) Date: Tue, 26 Apr 2022 21:20:01 +1000 Subject: iOS Per-app VPN Message-ID: <36BB837F-F667-4DD7-A410-042E923C4914@twopicode.com.au> Hello, I'm developing an iOS app to be used as a per-app VPN. When opening an app that I've designated to use the VPN, the VPN connects, but internet does not work. If I change the configuration payload type back to "com.apple.vpn.managed" to work as a normal VPN, it works, so I believe the rest of details are correct. The only thing I've got to go on at the moment is I noticed this message pop up in the logs a number of times: "[NET] Received a packet with unknown IP version". Not sure if this is part of the problem or not. Any assistance would be much appreciated! Thanks, James From feld at feld.me Thu Apr 28 13:14:13 2022 From: feld at feld.me (Mark Felder) Date: Thu, 28 Apr 2022 09:14:13 -0400 Subject: [MacOS] DNS search path not working? Message-ID: <80f2d9f4-9917-4e59-87fc-6713e80b1880@www.fastmail.com> Hello, I've observed this on MacOS 12 Monterey. I have also tested on iOS 15.4.1 where it works as expected. (I know they share the same codebase). On MacOS I have my DNS configured correctly as DNS = 1.2.3.4, int.foo.com but it doesn't seem to actually work. e.g., if I have a host named server.int.foo.com I cannot just "ping server"; I have to use the FQDN of server.int.foo.com. This behavior works correctly with an OpenVPN connection using the Viscosity software. I have compared the output of scutil --dns and verified that both OpenVPN and Wireguard appear to generate identical DNS configuration. I'm not sure where else to look for differences between what OpenVPN/Viscosity and Wireguard are doing. Any tips? Thanks! Mark -- Mark Felder feld at feld.me From andrew-wireguard at pileofstuff.org Fri Apr 29 17:32:54 2022 From: andrew-wireguard at pileofstuff.org (Andrew Sayers) Date: Fri, 29 Apr 2022 18:32:54 +0100 Subject: bug(?): Wireguard should allow packets from multiple peers Message-ID: <01945803-1ae8-135b-17d8-3e5504548763@pileofstuff.org> Hi, I think this is a bug, but some of it is beyond me. This e-mail might actually just be a request for help :) In some cases, an address can be associated with multiple peers. I'll describe a specific scenario below, but in short: a device might have peers with different-length netmasks, and might send and receive packets via different routes depending on configuration of devices across the network. A configuration similar to the one described below causes the error "Packet has unallowed src IP" for the kernel backend, and causes "packet with disallowed source address" for the Go backend. See https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireguard/receive.c#n415 and https://git.zx2c4.com/wireguard-go/tree/device/receive.go#n437 for the start of the relevant blocks. I assume other backends behave similarly, but don't have relevant test devices to hand. If I understand correctly, these blocks only accept a *single* valid peer. I'll argue below that behaviour is incorrect, but if it's right, the message could stand to be improved.? The kernel backend message reads: ??? "%s: Packet has unallowed src IP (%pISc) from peer %llu (%pISpfsc)\n" Something like the following would be more helpful: ??? "%s: Packet has incorrect src IP (%pISc) from peer %llu (%pISpfsc) instead of peer %llu (%pISpfsc)\n" Using the word "incorrect" and specifying the (single) correct value would indicate there's only one right value and would provide a hint to fix it. To see why multiple peers should be allowed, consider the following: Alice and Bob each have a home server and a phone with a networked camera. They would like their servers to regularly download pictures from the phones, and would occasionally like to access the other's camera from their own phone. Their servers are reliably accessible over the Internet, while their phones are behind firewalls and change address frequently. They need to create a VPN that lets all four devices communicate. They don't want to unnecessarily forward packets between servers, and don't want to reconfigure their phones when they add more devices. So they create an "Alice and Bob" subnet with IPv6* prefix `fdab::`. Alice's phone's Wireguard configuration looks like this: ??? [Interface] ??? # Alice's phone has a single IP on the VPN: ??? Address = fdab:A1ce::1/128 ??? [Peer] ??? # Alice's phone accepts all devices verified by her server: ??? AllowedIPs = fdab::/16 ??? Endpoint = alices-server.example.com:51820 ??? [Peer] ??? # Connect directly to Bob's server where possible: ??? AllowedIPs = fdab:B0b::/64 ??? Endpoint = bobs-server.example.com:51820 Bob's phone's configuration is the inverse: ??? [Interface] ??? # Bob's phone has a single IP on the VPN: ??? Address = fdab:B0b::1/128 ??? [Peer] ??? # Bob's phone accepts all devices verified by his server: ??? AllowedIPs = fdab::/16 ??? Endpoint = bobs-server.example.com:51820 ??? [Peer] ??? # Connect directly to Alice's server where possible: ??? AllowedIPs = fdab:A1ce::/64 ??? Endpoint = alices-server.example.com:51820 When Alice's server tries to access Bob's camera, it sends packets directly to his phone.? Bob's phone sees a packet with a `fdab:A1ce::` source and peer `alices-server.example.com`.? That's fine - it accepts the packet. But when Alice tries to access Bob's camera from her phone, the phone sends those packets via Bob's server.? Bob's phone sees a packet with a `fdab:A1ce::` source and peer `bobs-server.example.com`. Wireguard rejects these packets in my tests, presumably because it expects Alice's packets to come from Alice's server. Instead, Wireguard should accept packets from any peer with a matching IP prefix in `AllowedIPs`. To reply in advance to some obvious counterarguments: Yes, this creates a needlessly asymmetric route (Bob's phone receives messages via Bob's server and replies via Alice's server).? You can argue that's bad for complexity or good for privacy.? So long as the packets get to their destination, I'd argue it doesn't matter. Yes, this two-user example would be better solved with a star network around either Alice or Bob's server.? The value is more obvious at scale, as load gets distributed between multiple servers.? If you prefer, you can add Carol and Dave to the network with configurations similar to the above. No, this can't be solved by selecting a different "correct" peer. That would force the servers to route data between them, adding an extra hop and wasting bandwidth. No, this can't be solved by telling the phones about each other. Even if we could work around whatever firewall the phone might be behind, and we could update DNS entries quickly enough when devices change address, Alice and Bob would have to manually update their phones for every device on the network.? That's fine with the four nodes in the example, but not practical at any greater scale. - Andrew Sayers * I'm just using IPv6 addresses for readability, although IPv6's larger ? address space might cause more people to notice this issue