.
Is this correct, and do, therefore, all handshakes involving cookies take
at least 5 seconds to complete?
Thanks,
Reid Rankin
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
FWIW, all those ports (4500, 1500, 500) seem to work for me with iOS 13 and
WireGuard for iOS build 0.0.20190610 (13).
On Wed, Sep 25, 2019 at 6:03 PM John huttley
wrote:
> Hi,
>
> Port 4500 is the IPSec UDP nat port and 500 is IKE.
>
> Anyconnect uses ISPEC so I think those ports are simply in
Won't help -- a keepalive is by definition the minimum possible size frame.
That means not just that it's a predictable size, but that everything that
size must be a keepalive, randomized interval or not.
To get the kind of effect you're looking for, you'd need to send actual
dummy data -- which,
I've been thinking about wg-dynamic -- or something quite like it -- a
lot in recent months, and I've had some ideas I think are worth
sharing even though I haven't figured out an ideal final form for them
yet.
Just to let you know where I'm coming from (and to add to the
community gestalt of pote
That's a neat tool, and I'd probably use it in my own projects -- I'm
a big fan of the shell-script-only approach for userland tools -- but
the algorithm it uses has a few rough edges I'd prefer didn't get
standardized:
- The hash is taken over a (newline-terminated!) Base64-encoded key
and not th
I looked at something similar, but I really don't want to pay the
extra overhead -- and it just feels wrong to use
IP-in-Ethernet-in-GRE-in-UDP-in-IP(-in-WG-in-UDP-in-IP) if you don't
have to for routing purposes. (Version 2.0 of the product I'm working
on might use something similar for dynamic ro
I've been working on this a bit from a completely independent
perspective: bootstrapping embedded systems which have a persistent
keypair, but no persistent storage for stuff like `AllowedIPs`
assignments. In my usecase, the by-convention assignment of an IPv6
link-local address to each WireGuard p
> 2. There is very little practical utility. In WireGuard, both sides
> must _already_ preshare their public keys, and there's no way around
> this.
Well, it looks like you've discovered the method behind my madness!
Specifically, while a handshake *initiator* must know the public key
of the respo
> Fun fact: initial versions of WireGuard from years ago weren't like
> this. We wound up redoing some crypto and coming up with the `_psk2`
> variant for this purpose. I'm glad it's useful. I'm interested to
> learn: what are you doing this for? Got any code online?
That's a dangerous question to
A while ago, I included a link to a Gist containing `wg-lla.sh`, a
utility for calculating and assigning IPv6 Link-Local Addresses to
WireGuard peers based on a hash of their public key, which was based
on a shell-script implementation of Blake2s. At the time it was
intended as a proof-of-concept s
I looked at this a while back. As far as I could tell, there's nothing
fundamental about the protocol or the security model that prevents it
from happening; conceptually, it's as simple as overlapping AllowedIP
ranges. This is easy for incoming traffic, but outgoing traffic is
more difficult; each
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 those ranges in its
AllowedIPs. (Actually,
WireGuard doesn't care what address V has, because peers are defined
by their public key. If V switches from A1 to A2, upon receiving a
handshake packet from V's key from the address A2, B will start
sending packets for V out to A2. Incoming packets can arrive from any
IP; if they're from a connect
13 matches
Mail list logo
