[PATCH] wireguard-tools: embeddable-wg-library: add named wg_endpoint union
Hello,
It would be useful to have a named wg_endpoint type in the embeddable wg
library. It's added by the attached patch.
/Mikael
>From 62b35cb221af7208399fced86660585080c688f5 Mon Sep 17 00:00:00 2001
From: Mikael Magnusson
Date: Sat, 7 Nov 2020 13:32:56 +0100
Subject: [PATCH] embeddable-wg-library: add named wg_endpoint union
Define wg_endpoint as a named union to allow users of the emeddable
library to use the type in function arguments, variables etc.
Signed-off-by: Mikael Magnusson
---
contrib/embeddable-wg-library/wireguard.h | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/contrib/embeddable-wg-library/wireguard.h b/contrib/embeddable-wg-library/wireguard.h
index fbd8765..328fcb4 100644
--- a/contrib/embeddable-wg-library/wireguard.h
+++ b/contrib/embeddable-wg-library/wireguard.h
@@ -40,17 +40,19 @@ enum wg_peer_flags {
WGPEER_HAS_PERSISTENT_KEEPALIVE_INTERVAL = 1U << 4
};
+typedef union wg_endpoint {
+ struct sockaddr addr;
+ struct sockaddr_in addr4;
+ struct sockaddr_in6 addr6;
+} wg_endpoint;
+
typedef struct wg_peer {
enum wg_peer_flags flags;
wg_key public_key;
wg_key preshared_key;
- union {
- struct sockaddr addr;
- struct sockaddr_in addr4;
- struct sockaddr_in6 addr6;
- } endpoint;
+ wg_endpoint endpoint;
struct timespec64 last_handshake_time;
uint64_t rx_bytes, tx_bytes;
--
2.25.1
Re: Nested Wireguard tunnels not working on Android and Windows
On 2021-03-01 21:09, i iordanov wrote: Hi Frank, On Mon, Mar 1, 2021 at 9:42 AM Frank Carmickle wrote: Maybe it's a bug and not a feature? It seems to me that you would have no way of setting the MTU on the inner tunnel. That's true - other than inefficient packet fragmentation, is there anything else that would be an issue? It's possible to configure the MTU for each route on Linux. (Obviously you can't use the extremely simple wg-quick script for this.) Is there a reason why you can't try multiple interfaces? I cannot bring up more than a single interface on Android. I am not sure about interface management on Windows with wg.exe, but wireguard.exe certainly does not permit multiple interfaces to be brought up. The WireGuard app on Android also can't use a VPN address as the source of WireGuard packets. Only non-VPN addresses are supported. Which means currently the WireGuard app on Android can't be used for nested tunnels.
Re: Openwrt wg0 behaves not alike that on Fedora: why?
On 2020-06-14 20:19, Sergey Ivanov wrote: Hi, I have a question about wg0 on OpenWRT not forwarding packets from one client to another. I have a laptop at home in my home LAN, and a computer at work in a very restricted LAN. They can not see one another. I spent a lot of time trying to get them connected by adding their wg0's IP addresses to the AllowedIPs on my home router running OpenWRT. I saw pings from each of them successfully decrypted (I've used ping with patterns) on the OpenWRT wg0, but they never got routed further. When I decided to try to move the same AllowedIPs from OpenWRT's wg0 to my desktop Fedora, it immediately worked. It looks like some sort of setting like isolation of the clients, or hairpin mode which is different on OpenWRT than on Fedora. Can someone help and suggest what I should look at? I'd like to have it working on the router which is all time on. You should look at the firewall in OpenWrt. It's probably dropping or rejecting the packets. In particular look at the forward option of the firewall zone assigned to wg0. From the OpenWrt Firewall - Zone Settings GUI: the forward option describes the policy for forwarded traffic between different networks within the zone. Since WireGuard is a routed (and not bridged) VPN the above setting can also control forwarding between hosts on the same network.
wireguard-go: IpcGetOperation: return peers in sorted order
Hello,
I have an improvement to IpcGetOperation in wireguard-go.
uapi: IpcGetOperation: return peers in sorted order
Sort peers based on the public key.
The pros of using a sorted peer list is that the order doesn't change in
each ipc operation, or execution of the "wg showconf" command. Which
could be the case previously with an unsorted peer list.
The output from git format-patch is attached. The patch is also
available at
https://cgit.m7n.se/pub/wireguard-go/commit/?id=027bf58651f1a7b2be1bedfde187e5277a13f48e
/Mikael
>From 027bf58651f1a7b2be1bedfde187e5277a13f48e Mon Sep 17 00:00:00 2001
From: Mikael Magnusson
Date: Sun, 22 Sep 2019 23:13:30 +0200
Subject: [PATCH] uapi: IpcGetOperation: return peers in sorted order
Sort peers based on the public key.
The pros of using a sorted peer list is that the order doesn't change in
each ipc operation, or execution of the "wg showconf" command. Which could
be the case previously with an unsorted peer list.
Signed-off-by: Mikael Magnusson
---
device/uapi.go | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/device/uapi.go b/device/uapi.go
index 72611ab..bd66451 100644
--- a/device/uapi.go
+++ b/device/uapi.go
@@ -7,9 +7,11 @@ package device
import (
"bufio"
+ "bytes"
"fmt"
"io"
"net"
+ "sort"
"strconv"
"strings"
"sync/atomic"
@@ -30,6 +32,42 @@ func (s IPCError) ErrorCode() int64 {
return s.int64
}
+type PeerInfo struct {
+ pubkey NoisePublicKey
+ pubkeySlice []byte
+ peer *Peer
+}
+
+type PeerInfoList []PeerInfo
+
+func (list PeerInfoList) Len() int {
+ return len(list)
+}
+
+func (list PeerInfoList) Less(i, j int) bool {
+ k1 := list[i].pubkeySlice
+ k2 := list[j].pubkeySlice
+
+ return bytes.Compare(k1, k2) == -1;
+}
+
+func (list PeerInfoList) Swap(i, j int) {
+ list[i], list[j] = list[j], list[i]
+}
+
+func (device *Device) GetSortedPeers() PeerInfoList {
+ peers := make(PeerInfoList, 0, len(device.peers.keyMap))
+ for pubkey, peer := range device.peers.keyMap {
+ info := PeerInfo{}
+ info.pubkey = pubkey
+ info.pubkeySlice = info.pubkey[:]
+ info.peer = peer
+ peers = append(peers, info)
+ }
+ sort.Sort(peers)
+ return peers
+}
+
func (device *Device) IpcGetOperation(socket *bufio.Writer) *IPCError {
lines := make([]string, 0, 100)
send := func(line string) {
@@ -65,7 +103,8 @@ func (device *Device) IpcGetOperation(socket *bufio.Writer) *IPCError {
// serialize each peer state
- for _, peer := range device.peers.keyMap {
+ for _, peerInfo := range device.GetSortedPeers() {
+ peer := peerInfo.peer
peer.RLock()
defer peer.RUnlock()
--
2.17.1
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: IPv6 endpoint AND IPv4 fallback endpoint in roadwarrior scenario?
On 2019-09-30 09:52, Nico Schottelius wrote: At lookup time this works already. The problem is, if the underlying network topology changes and you need to reconnect via IPv4, when you had IPv6 underlying before. It doesn't work for me at least not with the Android app. I have a DNS name with both and A records that I use but the app seems to prefer IPv4 instead of IPv6. And I also can't detect any fallback to IPv6 if ICMP unreachable are sent for the IPv4 handshake attempts. /Mikma This is the feature that is - afaik- not currently implemented in wireguard. Henning Reich writes: Should a DNS entry Wirth one record and one A record solve thus problem? So the OS decide the best way to connect? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Crashes in wg_allowedips_insert_X
Hello list, I'm experiencing crashes in wg_allowedips_insert_v4 and wg_allowedips_insert_v6 in the wireguard kernel module. It happens both with the current snapshot (0.0.20190227-wg1~bionic) and the current git master (65e1f283). It seems to be caused by commit 20a230b3 (allowedips: maintain per-peer list of allowedips), since I can't trigger the bug(s) after reverting that commit. I have attached a dmesg dump of one general protection fault, and included two scripts below which triggers the bug(s). I am running Ubuntu 18.04 x86_64 with mainline linux 5.0.5 from https://kernel.ubuntu.com/~kernel-ppa/mainline. /Mikma #!/bin/sh name=wgtest key="pUZ1gXtFRRNeJFcBx2cGLELdeJTA00nTdQMuHjMYI2E=" ips=" 0.0.0.0/0 10.0.0.0/8 100.64.0.0/10 172.16.0.0/12 192.168.0.0/16 " allowed_ips=$(echo $ips | tr ' ' ',') ip l add $name type wireguard wg set $name peer $key allowed-ips $allowed_ips wg set $name peer $key allowed-ips '0.0.0.0/0' #!/bin/sh name=wgtest key="pUZ1gXtFRRNeJFcBx2cGLELdeJTA00nTdQMuHjMYI2E=" ips=" ::/0 17e5:9cdb:34ce:1800::/111 5000::/4 eb3f:fbec:5000::/37 9730:9636:d403:e000::/75 " allowed_ips=$(echo $ips | tr ' ' ',') ip l add $name type wireguard wg set $name peer $key allowed-ips $allowed_ips wg set $name peer $key allowed-ips '::/0' [ 47.508485] wireguard: loading out-of-tree module taints kernel. [ 47.508591] wireguard: module verification failed: signature and/or required key missing - tainting kernel [ 47.511058] wireguard: WireGuard 0.0.20190227 loaded. See www.wireguard.com for information. [ 47.511059] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld . All Rights Reserved. [ 47.517456] general protection fault: [#1] SMP PTI [ 47.517545] CPU: 0 PID: 1278 Comm: wg Tainted: G OE 5.0.5-050005-generic #201903271212 [ 47.517639] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 47.517750] RIP: 0010:wg_allowedips_insert_v4+0x298/0x3c0 [wireguard] [ 47.517845] Code: 00 00 48 83 c4 18 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 89 d9 48 8b 41 38 48 8b 71 30 48 8d 51 30 4c 89 31 49 81 c6 20 06 00 00 <48> 89 46 08 48 89 30 49 8b 46 08 49 89 56 08 4c 89 71 30 48 89 41 [ 47.518043] RSP: 0018:a9acc08579f0 EFLAGS: 00010282 [ 47.518131] RAX: dead0200 RBX: 8d949378a340 RCX: 8d949378a340 [ 47.518190] RDX: 8d949378a370 RSI: dead0100 RDI: [ 47.518283] RBP: a9acc0857a30 R08: 8d9494f9ad08 R09: 0003 [ 47.518376] R10: 3a2caa423744a024 R11: cea45abfb35c5be3 R12: [ 47.518472] R13: R14: 8d9493eb7e20 R15: 8d9494f9acf0 [ 47.518580] FS: 7f44a28c7740() GS:8d949f20() knlGS: [ 47.518690] CS: 0010 DS: ES: CR0: 80050033 [ 47.518780] CR2: 7ffed57ee0a0 CR3: 137ba004 CR4: 003606f0 [ 47.518907] Call Trace: [ 47.519055] set_peer+0x3b7/0x4c0 [wireguard] [ 47.519148] wg_set_device+0x2e9/0x4c0 [wireguard] [ 47.519243] genl_family_rcv_msg+0x1d8/0x410 [ 47.519334] genl_rcv_msg+0x4c/0x93 [ 47.519424] ? _cond_resched+0x19/0x30 [ 47.519511] ? genl_family_rcv_msg+0x410/0x410 [ 47.519598] netlink_rcv_skb+0x4f/0x120 [ 47.519699] genl_rcv+0x28/0x40 [ 47.519794] netlink_unicast+0x1a1/0x260 [ 47.519864] netlink_sendmsg+0x20d/0x3c0 [ 47.519881] sock_sendmsg+0x3e/0x50 [ 47.519931] __sys_sendto+0x114/0x1a0 [ 47.520019] ? __sys_recvmsg+0x59/0xa0 [ 47.520103] __x64_sys_sendto+0x28/0x30 [ 47.520193] do_syscall_64+0x5a/0x110 [ 47.520280] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 47.520371] RIP: 0033:0x7f44a21d7da7 [ 47.520457] Code: 64 89 02 48 c7 c0 ff ff ff ff eb b6 0f 1f 80 00 00 00 00 48 8d 05 61 db 2c 00 41 89 ca 8b 00 85 c0 75 18 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 79 f3 c3 0f 1f 80 00 00 00 00 41 57 41 56 4d [ 47.520654] RSP: 002b:7ffed5728f18 EFLAGS: 0246 ORIG_RAX: 002c [ 47.520787] RAX: ffda RBX: RCX: 7f44a21d7da7 [ 47.520892] RDX: 0074 RSI: 55c70f110450 RDI: 0003 [ 47.520985] RBP: 55c70f110450 R08: 7f44a24a99e0 R09: 000c [ 47.521077] R10: R11: 0246 R12: 55c70f1104a8 [ 47.521170] R13: R14: R15: 55c70f110260 [ 47.521285] Modules linked in: wireguard(OE) ip6_udp_tunnel udp_tunnel binfmt_misc veth btrfs zstd_compress xor raid6_pq ebtable_filter ebtables ip6table_nat nf_nat_ipv6 ip6table_filter ip6_tables xt_CHECKSUM xt_comment xt_tcpudp iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_mangle iptable_filter bpfilter bridge stp llc snd_hda_codec_generic ledtrig_audio crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 crypto_simd cryptd snd_hda_intel glue_helper snd_hda_codec snd_hda_core snd_hwdep joydev input_leds serio_raw
Re: Multiple VPN connections on Android
On 2019-03-26 15:17, Julian Orth wrote: Hello list, I'm currently using WireGuard on Android for two purposes: 1. Routing all traffic via a commercial VPN provider to protect myself on open wireless networks. 2. Connecting to my home network. Unfortunately WireGuard on Android does not allow me to do both of these things at the same time. I assume this is because VpnService [1] only allows 1 VPN connection at a time. Can't you add the peer for your home network to the same configuration (tun device) as the peer for the commercial VPN provider? It seems a straight forward solution to me if you are okay with the IP addresses assigned by the VPN provider. Has any thought been put into emulating multiple tun devices in user space? I don't see why you would need multiple tun devices. It is possible to add multiple IPv4 and IPv6 addresses to the tun device, but there may be a problem with the source address selection. Linux allows specifying a preferred address for each route, but it isn't possible in the Android API AFAIK. If you have a rooted device then you can potentially update the routing tables with the preferred source address for each VPN route. /Mikma Julian [1] https://developer.android.com/reference/android/net/VpnService.html ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Why does 'allowed-ips' affect route selection behavior?
On 04/15/2018 08:49 PM, Patrick O'Sullivan wrote: $ sudo ip route show default via 10.199.199.1 dev wlan0 10.111.111.0/24 dev wg0 proto kernel scope link src 10.111.111.100 10.199.199.0/24 dev wlan0 proto kernel scope link src 10.199.199.131 By this route table, traffic to e.g. 4.2.2.1 should use 10.199.199.1. Packet captures were showing traffic trying to instead use wg0. Then I found this: $ sudo ip route get 4.2.2.1 4.2.2.1 dev wg0 table 51820 src 10.111.111.100 cache Can someone please explain this behavior? Table 51820 is the default table used by wg-quick. From wg-quick's man page: It infers all routes from the list of peers' allowed IPs, and automatically adds them to the system routing table. If one of those routes is the default route (0.0.0.0/0 or ::/0), then it uses ip-rule(8) to handle overriding of the default gateway. /Mikma ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wg-ip, a tool to assign automatic ip addresses to wireguard interfaces
On 04/12/2018 01:42 PM, Christophe-Marie Duquesne wrote: Long story short, you need a proper central server that will find the next ip address, or you need to stick to ipv6 (and in that case the address space makes it pointless to do that check). I think one option is to use the DHCPv4-over-DHCPv6 (DHCP 4o6) Transport defined in RFC 7341. In that case you would need a link-local IPv6 address which is used with DHCPv6. Via DHCPv6 you will be able to receive the DHCP 4o6 server address option. And then request an IPv4 address using the DHCP 4o6 server. https://datatracker.ietf.org/doc/rfc7341/ /Mikma ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
