[ANNOUNCE] WireGuard Snapshot `0.0.20180413` Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, A new snapshot, `0.0.20180413`, has been tagged in the git repository. Please note that this snapshot is, like the rest of the project at this point in time, experimental, and does not consitute a real release that would be considered secure and bug-free. WireGuard is generally thought to be fairly stable, and most likely will not crash your computer (though it may). However, as this is a pre-release snapshot, it comes with no guarantees, and its security is not yet to be depended on; it is not applicable for CVEs. With all that said, if you'd like to test this snapshot out, there are a few relevent changes. == Changes == * wg-quick.8: fix typo * wg-quick: hide errors on save This fixes a small regression in the resolvconf save handling on Debian. * compat: stable kernels are now receiving b87b619 * compat: silence warning on frankenkernels * compat: support OpenSUSE 15 Usual set of fixes for weird kernels. * curve25519: use precomp implementation instead of sandy2x * curve25519: use cmov instead of xor for cswap * curve25519: memzero in batches * curve25519: precomp const correctness Rather than using sandy2x, which requires use of the vector registers and simd instructions (and therefore thermal throttling and register save/restores), we instead use BMI2 and ADX instructions to achieve better performance, using: - https://eprint.iacr.org/2017/264 - https://github.com/armfazh/rfc7748_precomputed * curve25519: add self tests from wycheproof * chacha20poly1305: add self tests from wycheproof Wycheproof now provides sneaky test vectors, so we've imported them into our self-tests to mitigate regressions. More info can be found at: - https://github.com/google/wycheproof As always, the source is available at https://git.zx2c4.com/WireGuard/ and information about the project is available at https://www.wireguard.com/ . This snapshot is available in tarball form here: https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20180413.tar.xz SHA2-256: 419ef147c729db4442b9c2bb5ce4f76ae0807bd820d60d1dce17311885e97251 BLAKE2b-256: 2193f68c2e0511dfc31001cd416e99ab62693e225d1b6fa5c76ab325ee289f4e If you're a snapshot package maintainer, please bump your package version. If you're a user, the WireGuard team welcomes any and all feedback on this latest snapshot. Finally, WireGuard development thrives on donations. By popular demand, we have a webpage for this: https://www.wireguard.com/donations/ Thank you, Jason Donenfeld -BEGIN PGP SIGNATURE- iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAlrQCVgQHGphc29uQHp4 MmM0LmNvbQAKCRBJ/HASpd4DrtMuEACFm9Si1izgDAkf56A6IDjHQLj/vtpzPs5w RQUj+7AnLL2C2tD7ShiX1diUQeCIlqEeRBX3BDlK/8B/H8XW6SnUp552NLWopOdK XjwnxPZOhoCWuL2JZaVlAKkZ0qM/KvVgF/o9s4f5qcFYIALvqziQOXjV/wGRrs60 UdBvfdRtH9Z/+4QtDieSQDyA/aIakdTscWgpumFQMKqozTbRMqJ7jAfXAkFCmAi1 7dUw8jeMpTWS/3P9EXJ2IzWdKg1sPI8Gdz0ckEctWOavQhJuP/nVoilzg29gWB44 01gdrs9K6WDSXt6T+0jVHSUa0Ubdw/rqzqwEDfhfif5IBzbpxA8oKEKoy7imEeTh ceCDHMSv6P2z8OD7wVqlOW5BRem1kvzAG2jQxwZXX33p1joD0KtgxEOR+uNM+eL6 xkwgRm79TZ3mvJU0LV9XfJLkTXmlhWhcb1WqhVGZZTnfqy1HCX1rChYsG3Zi7zSH 1zWOr8wkv0suESslJioO7EpCMqWQCMNc+WjgeOV42EH+anuRbW4uQAAbv8DGgDXB LrPXbrucm/UHA4tNvSkWDJVxZls6Ya0PbfSnpNMnu6Yyxfr8QZkhkEru+c/IU7cc SWugvgUPRK//CjdJeDZR4yuNOiaJytkSAbtPBdnPk5Aw5UdiUeZ4AEpkPzxnb4NL RNqSPwZuIQ== =jRZh -END PGP SIGNATURE- ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Question about peers count
The max is 1048576 per interface, but if this becomes a problem, I can increase this significantly. [PS: I'm back from holidays now and I'll be working through the mailing list backlog over the next few days.] ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Question about peers count
Hi Vyacheslav, Yes - Wireguard can handle that easily. >From one of Jason's posts earlier in the month: "I have a script I run during development that sets up thousands of interfaces, *each with **hundreds of thousands of peers* [...]" So ... you'll be fine :) E Q: Why is this email five sentences or less? A: http://five.sentenc.es On Wed, 28 Mar 2018, at 09:13, Tiraen wrote: > Good evening > > the question of such plan: > > Is the number of nodes that I can specify in configs be limited? Those > if I'm using a software to organize a ptp network on a principle, for > example 500 minus 1 node, this will work?> > > > -- > With best regards, > > Vyacheslav Yakushev, > > Unix system administrator > > https://t.me/kelewind> _ > 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
Conflict with broadcom component.
I installed Wireguard on my Asus router. Some sites work but others slow or do not response. I tried adjust MTU but no luck. Kernel makes following error messages. Apr 1 16:17:43 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when adding flow net_p=ffc0100cba60 dir=0 old_key=0x2091 new_key=0x2092 Apr 1 16:17:43 kernel: ^[[0m Apr 1 16:18:04 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when adding flow net_p=ffc0100cba60 dir=0 old_key=0x2092 new_key=0x2093 Apr 1 16:18:04 kernel: ^[[0m Apr 1 16:18:05 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when adding flow net_p=ffc0100cba60 dir=0 old_key=0x2093 new_key=0x2094 Apr 1 16:18:05 kernel: ^[[0m Apr 1 16:18:10 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when adding flow net_p=ffc0100cba60 dir=0 old_key=0x2094 new_key=0x2095 Apr 1 16:18:10 kernel: ^[[0m Apr 1 16:18:11 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when adding flow net_p=ffc0100cba60 dir=0 old_key=0x2095 new_key=0x2096 Apr 1 16:18:11 kernel: ^[[0m Apr 1 16:18:41 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when deleting flowfor net_p=ffc0110eb010 Apr 1 16:18:41 kernel: ^[[0m Apr 1 16:19:17 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when deleting flowfor net_p=ffc0100cba60 Apr 1 16:19:17 kernel: ^[[0m Apr 1 16:19:52 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when deleting flowfor net_p=ffc0110eb010 Apr 1 16:19:52 kernel: ^[[0m Apr 1 16:20:01 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when deleting flowfor net_p=ffc0100cba60 Apr 1 16:20:01 kernel: ^[[0m Apr 1 16:20:10 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when deleting flowfor net_p=ffc0100cba60 Apr 1 16:20:10 kernel: ^[[0m Apr 1 16:20:10 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when deleting flowfor net_p=ffc0100cba60 Apr 1 16:20:10 kernel: ^[[0m Apr 1 16:20:28 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when deleting flowfor net_p=ffc0100cba60 Apr 1 16:20:28 kernel: ^[[0m Apr 1 16:20:55 kernel: ^[[0;33;41mBLOG ERROR blog_request :blog_key corruption when deleting flowfor net_p=ffc0110eb010 Apr 1 16:20:55 kernel: ^[[0m That codes in here. https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src-rt-5.02hnd/kernel/linux-4.1/net/core/blog.c Can you guys review and tell what's wrong? I don't know computer code :(. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
few wg peers over the same port in the main office? Cryptokey routing
First of all a BIG thanks to developers for great job! There is a main office with WG running on Lede reboot (17.01.4) with ports 51820 and 51821. Until I've two peers, one pointing to port 51820 and 2nd to 51821 everything worked fine. Now I want to add another one peer to have 3 remote peers in total. The questions is: should I open the new port for each remote peer to connect? It's how wg works? How to run few tunnels/peers on the same port 51820 for example? Does Cryptokey routing can work in this way over one port only instead opening third one 51822? As If I try to use the same port for two peers, the 2nd peer for the same port will not create interface. See evidence bellow. Once ifconfig brings T1 interface up (listening on 51820 port), the TU interface can't be raised up as it listens on the same port 51820. # Lede reboot (17.01.4) root@OpenWrt:~# wg interface: T1 public key: listening port: 51820 peer: endpoint: x.x.13.235:56649 allowed ips: p.p.5.0/24 latest handshake: 45 seconds ago transfer: 150.31 KiB received, 286.11 KiB sent interface: RA public key: private key: (hidden) listening port: 51821 peer: endpoint: x.x.125.213:51820 allowed ips: p.p.30.0/24, 10.1.1.16/30 latest handshake: 54 seconds ago transfer: 285.81 KiB received, 14.89 KiB sent interface: TU public key: private key: (hidden) listening port: 51820 # If I use THE SAME as for T1 interface, it won't start. How to solve this? peer: endpoint: x.x.147.136:51820 allowed ips: p.p.57.0/24, 10.2.1.32/30 With p - rfc1918 private address space address is marked (local addresses) Mon Feb 26 15:28:57 2018 daemon.notice netifd: Interface 'T' is now up Mon Feb 26 15:28:57 2018 daemon.notice netifd: Network device 'T' link is up Mon Feb 26 15:28:57 2018 daemon.notice netifd: Interface 'RA' is now up Mon Feb 26 15:28:57 2018 daemon.notice netifd: Network device 'RA' link is up Mon Feb 26 15:28:57 2018 daemon.notice netifd: Interface 'TU' is now down Mon Feb 26 15:28:58 2018 daemon.notice netifd: Interface 'TU' is setting up now Mon Feb 26 15:28:58 2018 daemon.notice netifd: Interface 'wan' is now up Mon Feb 26 15:28:59 2018 kern.err kernel: [1972650.446719] wireguard: TU: Could not create IPv4 socket Mon Feb 26 15:28:59 2018 daemon.notice netifd: Interface 'TU' is now up root@OpenWrt:~# ifconfig RA Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.1.1.16 P-t-P:10.1.1.16 Mask:255.255.255.252 UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1 RX packets:3 errors:0 dropped:0 overruns:0 frame:0 TX packets:3 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:444 (444.0 B) TX bytes:612 (612.0 B) T1 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 UP POINTOPOINT RUNNING NOARP MTU:1420 Metric:1 RX packets:312 errors:0 dropped:0 overruns:0 frame:0 TX packets:312 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:26400 (25.7 KiB) TX bytes:40164 (39.2 KiB) Where is TU interface? Or it can't be raised because it listens on the same port 51820 as T1 tunnel? Thanks You! ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [patch] add support for peer names using a file in userspace
On 8 December 2017 at 19:45, Jason A. Donenfeld wrote: > Absolutely not. If something like this lands, it will be called > "Description=" or the like, as another attribute of a peer. There's no > reason to make the section parser more complicated, when this is > essentially just another key value. +1. Description, Comment, or maybe Name would be handy. I got > 200 peers. I am getting hard times checking for peer status. It would be nice to be able to do something like this: wg | grep -A6 -B6 my_Description_or_Comment Or maybe even simpler: wg show peer by_Name To show current status of selected peer. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Question about peers count
Good evening the question of such plan: Is the number of nodes that I can specify in configs be limited? Those if I'm using a software to organize a ptp network on a principle, for example 500 minus 1 node, this will work? -- With best regards, Vyacheslav Yakushev, Unix system administrator https://t.me/kelewind ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Working only one way
Hi Luis, On Tue, Apr 10, 2018 at 3:16 PM, Ing. Luis Felipe Domínguez Vega wrote: > 1 - Can I change the length (to 4096 bits for example) of private key? or is > not neccesary, I am a little paranoic with this kind of security cipher. > No. WireGuard uses cryptographic primitives which are state-of-the-art, with a large security margin. No options means there's nothing for users to misconfigure, or any risk of so called downgrading attacks. Also note that the bit length you are asking for is normal for RSA, but enormous for elliptic curve based primitives, which is what WireGuard uses. Cheers, Fredrik ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Working only one way
On 04/09/2018 10:17 PM, Ing. Luis Felipe Domínguez Vega wrote: Hello people, i currently installed wireguard (So easy !!), but i have a problem i have ping from server -> client, but not client -> server, when in server I execute tcpdump -i empresa only i see ICMP request and not response: Config server: [Interface] Address = 10.11.2.0/24 This is the network address which I don't think you should use. Try any address within 10.11.2.0/24 except 10.11.2.0, 10.11.2.2, and 10.11.2.255. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
Hi Riccardo, Welcome! Not off-topic at all. Your config looks fine to my eyes; I don't think you _need_ different ports per endpoint, but I might be wrong. With your tcpdump, if you can see incoming ICMP requests you should see outgoing ones too -- make sure they're not coming in on wg0 and going out on eth0; I've had that happen to me before. Can you send through the output of: `tcpdump -ni any icmp`? E Q: Why is this email five sentences or less? A: http://five.sentenc.es On Thu, 12 Apr 2018, at 21:09, Riccardo Berto wrote: > WireGuard doesn't always work with my devices. > I ran out of options for troubleshooting it so I'm writing here, hoping > for a stable solution. I see it's not a strict devel-only mailing list > but if I'm off-topic I apologize in advance and I'll fade-out in the > background, waiting for better times. > > Here's my problem: WireGuard "sometimes" works. I have a client that > always talks with the server without problems (the laptop, 10.0.0.4), it > always pings and trasfers data correctly. It just works as expected. I > have 2 others (Raspberry Pis: 10.0.0.2, 10.0.0.3) that don't work most > of the time. I tried enabling the PersistentKeepalive feature on those > and the WireGuard interface has some low traffic due to it but no chance > of pinging or having traffic with them 99 times out of 100. "tcpdump -i > wg0" shows ping requests, from both sides, but no answers. > In the rare occasions they work, I can ping everyone from every client, > as expected with my configuration files. > > Also, with all the devices I tried both the new systemd-networkd's > WireGuard implementation and systemd's wg-quick@wg0.service method, as > well as testing manually with wg-quick. The systemd version is 238. > Archlinux is running on every node and I'm using the latest publicly > available WireGuard snapshot as of writing this, 20180304. > > > # > # Server config (VPS on vultr.com): # > # > [Interface] > Address = 10.0.0.1/24 > SaveConfig = true > ListenPort = 21 > PrivateKey = > > [Peer] > PublicKey = > AllowedIPs = 10.0.0.3/32 > Endpoint = Client1:51820 > PersistentKeepalive = 30 > > [Peer] > PublicKey = > AllowedIPs = 10.0.0.4/32 > Endpoint = Client3:51821 > > [Peer] > PublicKey = > AllowedIPs = 10.0.0.2/32 > Endpoint = Client2:21 > PersistentKeepalive = 30 > > > # > # Client 1 config (Raspberry Pi 3): # > # > [Interface] > Address = 10.0.0.3/24 > ListenPort = 51820 > PrivateKey = > > [Peer] > PublicKey = > AllowedIPs = 10.0.0.1/24 > Endpoint = VPS:21 > > > # > # Client 2 config (Raspberry Pi 3): # > # > [Interface] > Address = 10.0.0.2/24 > PrivateKey = > ListenPort = 21 > > [Peer] > PublicKey = > AllowedIPs = 10.0.0.1/24 > Endpoint = VPS:21 > > > ## > # Client 3 config (personal laptop, x86_64): # > ## > [Interface] > Address = 10.0.0.4/24 > ListenPort = 51821 > PrivateKey = > > [Peer] > PublicKey = > AllowedIPs = 10.0.0.0/24 > Endpoint = VPS:21 > > > > Any help is appreciated. > ___ > 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: 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
Re: wg-ip, a tool to assign automatic ip addresses to wireguard interfaces
On 12.04.2018 13:42, Christophe-Marie Duquesne wrote: > And for certain reasons I prefer to use ip4. I'd recommend a closer look at those reasons. In other words: whatever problem prevents you from using IPv6, get them fixed. -- -- Matthias Urlichs signature.asc Description: OpenPGP digital signature ___ 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
i once had written a script for some openWRT (lede) Routers for Freifunk,
first of all, take ipV6 inside your tunnel, and mix localnet V6
Addresses with the MAC - this way you get a very distinct pair of V6
Address and Key
This assumes that a Server has fixed ip and key.
keyline in Setup is this
uci set wireguard.wireguard.ownip=fdf1::$(cat
/sys/class/net/eth0/address|awk 'BEGIN{FS=":"}{print $1$2":"$3$4":"$5$6}')
found here, if you want to look around a bit
https://github.com/viisauksena/gluon-mesh-wireguard/blob/cb77788ee49fe5b81789d01eed49aa30e971dd8e/files/lib/gluon/upgrade/405-wireguard
maybe this brings some new hints-- the gluon wireguard project has
actually stopped.
greetz
--
make the world nicer, please use PGP encryption
___
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
Weird. Once again, I did not receive this answer and saw it on the online archive. from https://lists.zx2c4.com/pipermail/wireguard/2018-April/002598.html: > > I could add this to the script, but I figured that for the number of > > peers I have and for the network ranges I am using, it is utterly > > pointless. How many peers do you intend to have? > > It will depend how popular the project will be. Theoretically it could > be 100'000 or even more peers. And for certain reasons I prefer to use > ip4. With this amount of peers, using such a method is a very, very bad idea. Even in the 10.0.0.0/8 range, so a 24 bits address space, generating pseudo-random ip addresses will not work. In that space, the probability of collision for a new peer is about 1-e^(- n^2/ 2^25) (see https://en.wikipedia.org/wiki/Birthday_problem#Approximations). - With n=2^12 (4096 peers), that is a 40% chance. - With n=2^13 (8192 peers), that is 85 %. - With n=2^14 (16384 peers), that is 99.9% - At n=2^15... My calculator already approximates this to 100%, and we are not even close to your target (32768 peers, we need to quadruple this to reach 100.000 peers). This means that randomly generating an address which does not collide with existing peers is increasingly more expensive, for each new peer. You will re-try more and more before you can generate a key pair that yields a non colliding ip address. This is simply not doable. 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). ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Troubleshooting WireGuard connections
WireGuard doesn't always work with my devices. I ran out of options for troubleshooting it so I'm writing here, hoping for a stable solution. I see it's not a strict devel-only mailing list but if I'm off-topic I apologize in advance and I'll fade-out in the background, waiting for better times. Here's my problem: WireGuard "sometimes" works. I have a client that always talks with the server without problems (the laptop, 10.0.0.4), it always pings and trasfers data correctly. It just works as expected. I have 2 others (Raspberry Pis: 10.0.0.2, 10.0.0.3) that don't work most of the time. I tried enabling the PersistentKeepalive feature on those and the WireGuard interface has some low traffic due to it but no chance of pinging or having traffic with them 99 times out of 100. "tcpdump -i wg0" shows ping requests, from both sides, but no answers. In the rare occasions they work, I can ping everyone from every client, as expected with my configuration files. Also, with all the devices I tried both the new systemd-networkd's WireGuard implementation and systemd's wg-quick@wg0.service method, as well as testing manually with wg-quick. The systemd version is 238. Archlinux is running on every node and I'm using the latest publicly available WireGuard snapshot as of writing this, 20180304. # # Server config (VPS on vultr.com): # # [Interface] Address = 10.0.0.1/24 SaveConfig = true ListenPort = 21 PrivateKey = [Peer] PublicKey = AllowedIPs = 10.0.0.3/32 Endpoint = Client1:51820 PersistentKeepalive = 30 [Peer] PublicKey = AllowedIPs = 10.0.0.4/32 Endpoint = Client3:51821 [Peer] PublicKey = AllowedIPs = 10.0.0.2/32 Endpoint = Client2:21 PersistentKeepalive = 30 # # Client 1 config (Raspberry Pi 3): # # [Interface] Address = 10.0.0.3/24 ListenPort = 51820 PrivateKey = [Peer] PublicKey = AllowedIPs = 10.0.0.1/24 Endpoint = VPS:21 # # Client 2 config (Raspberry Pi 3): # # [Interface] Address = 10.0.0.2/24 PrivateKey = ListenPort = 21 [Peer] PublicKey = AllowedIPs = 10.0.0.1/24 Endpoint = VPS:21 ## # Client 3 config (personal laptop, x86_64): # ## [Interface] Address = 10.0.0.4/24 ListenPort = 51821 PrivateKey = [Peer] PublicKey = AllowedIPs = 10.0.0.0/24 Endpoint = VPS:21 Any help is appreciated. ___ 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
> from https://lists.zx2c4.com/pipermail/wireguard/2018-April/002595.html: > > PS: you write that the "tool does not handle collisions", but does it > > recognize and/or warn about them? I.e. if a peer with the newly > > suggested IP exists already - will it warn? > > No, no detection is attempted. The script will not warn you. > > > For automation it would be nice to have some sort of "force" or > > "keep-trying" options, so the tool regenerates the keys trying to find a > > free IP and subsequently assigns it. With the enabled SaveConfig options > > the new IP will be saved in the config file... > > This is why there is a 'gen' command to make an ip for a single > pubkey. I do not see a good way to extract that info from a particular > wireguard interface, because this interface might not know all other > peers involved in the network, so it I find it pointless to scan for > collisions since you can do this and it will still go undetected. You are right. Such a scan only makes sense on a "central server" which knows _all_ other peers, but such a use case is quite common. Another easy way to let all peers be aware of all peers (complete N:N mesh) is through introduction of "includes" in the config file, as I've recently proposed: https://lists.zx2c4.com/pipermail/wireguard/2018-March/002561.html Unfortunately there was no feedback on that suggestion... > If you want absolutely want to be sure to generate a key pair which > generates an ip that is garanteed to not collide with existing peers, > it should be fairly straightforward. Assuming all the ips of existing > peers are in the file 'ips': > > for i in ($seq 1 1000); do # try 1000 times > privkey=$(wg genkey) > ip=$(echo $privkey | wg pubkey | xargs wg-ip gen) > if ! grep -qs "^$ip$" ips; then > echo privkey: $privkey > echo pubkey: $(echo $privkey | wg pubkey) > break > fi > done > echo "Could not generate a non colliding key" Thank you! I'm not that experienced with bash scripting so this will be useful! What I was thinking to implement is the following: there is a central publicly visible server with a script `add_peer` . Once called without any arguments, the script is supposed to automatically add a new peer to the configuration of the central server (i.e. to itself) and output a complete corresponding configuration for the peer. This way you can span a VPN automatically... > I could add this to the script, but I figured that for the number of > peers I have and for the network ranges I am using, it is utterly > pointless. How many peers do you intend to have? It will depend how popular the project will be. Theoretically it could be 100'000 or even more peers. And for certain reasons I prefer to use ip4. > By the way, I just took care of removing all bashisms and I added > automated testing of this script with the 'dash' shell. It should be > safe to run on platform where bash is not present, such as openwrt. Thank you! ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
