With two peers, A with persistent keepalive & B without, I am trying to
change the private key on peer A. First I update the public key for A at
B, then `wg set wg0 private-key ` on A. It takes roughly the length
of the persistent keepalive to reestablish pings from B to A.
If instead I up
I believe I found a solution to this problem. Will submit a patch once
I've done a bit more testing. ~Derrick
On 1/24/19 1:22 PM, Derrick Lyndon Pallas wrote:
[snip]
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c
Thanks for taking a look, I should have spent 30 more minutes
investigating myself. Please see the patch set I just submitted.
Resetting the handshake timer is also necessary or else it takes until
the expiration of that timer to actually happen in my setup. It seemed
worth putting into a utili
I just use DKMS to do it. Check out WireGuard to /usr/src, ln -s
WireGuard/src WireGuard-0, dkms add WireGuard/0. If it's not auto
building, have you tried dkms install WireGuard/0? ~D
On 2/21/19 2:57 PM, Arpit Gupta wrote:
Ya reboot did not solve this for me. I will read up on how I can
exec
I've had to drop to 1280 from Linode to several cellular carriers or else IPv6
fails. Ymmv, but the primary problem I've seen is MTU discovery failing because
the v6 message is being eaten but not the v4 message. Have you enabled
discovery in the kernel?
~Derrick • iPhone
> On Feb 28, 2019, at
Triffid, have you had a chance to test?
Jason, did you have any more thoughts? (You've clearly been busy given
all the recent announcements!) This is the second version, which
required a rebase but the code remained the same after verifying that
the process did not change at all.
Thanks, ~De
MTU discovery isn't supported widely in my experience. My rule has been to set
the interface to 1280, which is the minimum allowed.
~Derrick • iPhone
> On Apr 10, 2019, at 8:34 AM, Roman Mamedov wrote:
>
> Hello,
>
> I use WireGuard over IPv6 on a PPPoE connection. The Internet interface MTU
On 7/11/19 8:37 AM, Jason A. Donenfeld wrote:
Can you let me know if these work for you?
https://git.zx2c4.com/WireGuard/commit/?id=fffe613427d70a7470d34b6dedcab9ffb8b6b667
https://git.zx2c4.com/wireguard-go/commit/?id=a961aacc9f4dff9e617197c6433f8c9628928132
I don't have a Go setup and so di
I just released v0.0.1 of wgnlpy [1], a WireGuard Netlink connector for
Python.
It does not support the full range of Netlink operations at the moment.
Specifically, set_interface and set_peer only operate on a single peer
at time. (It is possible to clear peers or allowedips in bulk, however.
Why wouldn't this happen as an iptables rule?
If some AllowedIPs trick is working for you and you're using Python and the
kernel version of Wireguard, check out [1], which will allow you to
programmatically set up the interface.
FWIW, I'm not sure adding complication to AllowedIPs is the right
Doesn't a routing rule solve this issue?
~Derrick • iPhone
> On Aug 14, 2019, at 6:36 PM, Oliver Benning wrote:
>
> My setup (may be unrelated):
>
> I have a public endpoint hosted on Digital Ocean, which I connect to simply
> through its external IP address as the endpoint. It was setup usin
I recently ran into this issue. My solution was to sort a list of endpoint
addresses (not domains) by priority and first check whether the client had a
route to an address before picking it. It would be nice if Wireguard kept a
list of fallback addresses in case the currently active address stop
The private key is in kernel memory and is available via netlink and cli.
~Derrick • iPhone
> On Aug 24, 2019, at 12:01 PM, Andreas Karlsson wrote:
>
>> On 8/24/19 4:08 PM, Matthias Urlichs wrote:
>> Anyone with *root* access to the running machine can do that. They also
>> can trivially read t
/25/19 12:23 PM, Derrick Lyndon Pallas wrote:
I recently ran into this issue. My solution was to sort a list of endpoint
addresses (not domains) by priority and first check whether the client had a
route to an address before picking it. It would be nice if Wireguard kept a
list of fallback
Forcing later callers to assume state about a buffer is not better. Re:
strncpy, the explicit termination *is* required, since the destination
will not be null terminated if the source is the same size. Also,
doesn't this patch remove the "ago" response? ~Derrick
On 8/31/19 3:41 AM, Markus Gr
It allows it to work for hardware devices that emulate or simply do not
provide a real touchscreen, e.g. Android TVs. The feature requirement
for a real touchscreen is default enabled and must be explicitly
disabled. ~D
On 1/22/20 11:44 AM, Jason A. Donenfeld wrote:
Thanks for this.
On Wed,
You might also want to check out https://pypi.org/project/wgnlpy/ which is a
Wireguard configuration library for python.
~Derrick • iPhone
> On Feb 14, 2020, at 3:02 AM, Barrett Strausser wrote:
>
>
> I don't doubt that it can handle 1M peers.
>
> My question was more concerned with can an
Have you checked your MTUs? ~Derrick
On 5/6/20 9:57 AM, Mo Balaa wrote:
We are running WireGuard over WireGuard. It appears to work well;
however I am noticing some applications struggle to work reliably.
Lots of failed page loadss / timeouts. Any pointers on how I could go
about debugging thes
Note for the list: IPv6 has a minimum of 1280, which means 1360 in the
outer layer. ~Derrick
On 5/6/20 4:54 PM, Jason A. Donenfeld wrote:
On Wed, May 6, 2020 at 5:28 PM John Lauro wrote:
Wireguard is defaulting to 1420 MTU, the ethernet adapter is 1500 MTU,
and I have IPv6 completely disable
I've been using something similar for ORCHIDv2-ish addressing, q.v. [1].
from base64 import b64decode
from hashlib import shake_128
from ipaddress import IPv6Network
public_key = b64decode(...)
secret = "somesecret".encode('utf-8')
network = IPv6Network("2001:20::/28")
hash = shake_128(secret +
Thanks for updating!
FYI, I just added this LLA algorithm to the PublicKey class in [1] with
three caveats:
* it allows for injection into an arbitrary IPv6 or IPv4 address space
(default is the LLA/10 that wg-lla uses)
* it fails if the generated address is the network address or
broadcas
Andrew, if you'd like help creating a truly cross-platform library in
python, I'm happy to help. The reasons wgnlpy is currently Netlink-only
is that I was developing it for a Linux system and pyroute2 didn't
support Wireguard yet. If embeddable-wg-library supported UAPI and BSD
too, then hooki
I know this has come up a few times before, but if there was resolution,
I couldn't find it.
I am trying to set up a hub-and-spoke network with many clients
connected to a single concentrator. One application I need to support
relies on mDNS. Because Wireguard does not allow overlapping ranges
Toke, good to hear from you again!
Thanks for the pointer to ohybridproxy. Unicast conversion was on the
list of things to check out. Unfortunately, it appears to take manual
intervention on some platforms (e.g. MacOS) and does not work for
auto-discovery on others (e.g. iPhone). If I controll
On 9/21/20 4:24 AM, Jason A. Donenfeld wrote:
We've discussed this extensively and repeatedly. I made a few
proposals a few years ago that we discussed. It doesn't fit into
WireGuard's strong binding model.
Jason
As I mentioned, I looked through the archives before starting this
thread. Spec
Thanks for the reply. I definitely agree about not having magic, built
in ranges. If I were to more fully implement this, I'd likely separate
out MulticastIPs from AllowedIPs so that users do not unwittingly turn
an intended-unicast subnet into an accidentally-multicast subnet. It
would all, of
Thanks for the reply.
Since I can't control the peers (they're mostly just running the
official Wireguard apps), the way I've got it implemented is that
224.0.0.0/4 is explicitly in their lists of AllowedIPs. On the hub side,
I took approach (1) for the proof of concept.
If I were to extend
On 9/21/20 8:16 AM, Derrick Lyndon Pallas wrote:
As an aside, it looks like at least one Wireguard (protocol)
implementation [1] actually does implement all-or-nothing
multicast/broadcast in their client: note the AllowMulticast option in
[2]. They also explicitly enable ICMPv6 Neighbor
On 9/22/20 12:38 PM, Reid Rankin wrote:
While I'm all for multicast support, I don't think this is it. TunSafe
only has that option to allow you to turn off an extra anti-multicast
filter that's on by default and drops anything incoming from ff00::/8
or 224.0.0./3, even if it's from a peer with
29 matches
Mail list logo
