he traffic.
- --
Aaron Jones
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJaCWIOAAoJEIrwc3SIqzASMd4P/3JgXvsJ6iOK1LX+KMSt1htk
NF2FOek0084925vtJgPdJFhzxiyM23Xitwq0xFZcgMogRFkKB4anrJ
ssions with
the peer. WireGuard is not a client-server architecture; by removing the
endpoint, you are preventing this peer from initiating. This is only
useful if you're using it *as* a server, in which case roaming is
usually what you want, but not always.
- --
Aaron Jones
-BEGIN PGP SIGNATURE-
V
se.
As far as I understand it, you can dynamically add a new peer to the
interface with wg(8) with the same configuration (including Allowed
IPs and Endpoint) and then remove the old peer. If you are running
reliable protocols on top (e.g. TCP) their retransmit logic will
establish a new session with
can "set
> remove", but is there a simple command to take them all
> down? (One could obviously be scripted; just wondering if I'm
> missing that one's already there.)
# ip link del dev wg0
Regards,
Aaron Jones
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using G
new sessions can usually resume as if
nothing happened, even through a NAT (though if you are also behind a
NAT, source port randomisation may trip you up if you don't have it
forwarded through the remote one, but that's beside the point).
- --
Aaron Jones
-BEGIN PGP SIGNATURE-
Version
set wg0 private-key -' and
> 'wg set wg0 psk -'?
This should already be possible via `wg setconf wg0 /dev/stdin', no?
Regards,
Aaron Jones
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJaLgWzAAoJEIrwc3SIqz
, where restarting the
> daemon or having it reload its prefs is standard.
# wg addconf wg0 /etc/wireguard/wg0.conf
Regards,
Aaron Jones
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBA
er.
Someone in a position to fake NTP (which needs bidirectional
communication) is already in a position to block WG forever (by simply
refusing to forward its packets).
Additionally, there are a few very well-designed and secure NTP daemons
out there (such as OpenNTPd).
--
Aaron Jones
signature.asc
unsubscribe from the list and download monthly archives
from [1]. Any decent MUA can open these.
[0] https://lists.zx2c4.com/mailman/listinfo/wireguard
[1] https://lists.zx2c4.com/pipermail/wireguard/
Regards,
Aaron Jones
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using Gnu
have met you Jason :)
- --
Aaron Jones
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJad3ODAAoJEIrwc3SIqzASHR0P/1yn0azAslCrDI+AG/0frsS/
efhQq32b7+8L92qtbFh+eDOZDZPHvVu07EO5XW4G5jHQrZ
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/08/18 16:40, jungle Boogie wrote:
> If someone already has my ssh key, I'd revoke it - regardless if
> they had the password or not. Same with the WG key - shutdown the
> tunnel, remove the affected peer and start it back up.
No need to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11/08/18 22:52, Luiz Angelo Daros de Luca wrote:
> I see these wireguard extra features just like dhcp is. Nobody
> thinks about implementing dhcp inside kernel or even iproute
> tools.
The Linux kernel has a (minimal, non-configurable) DHCP
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/08/18 00:46, Jason A. Donenfeld wrote:
> This is in fact true, but I'm not sure we're planning on following
> suite with that kind of thing in kernel space for WireGuard...
Indeed. :)
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
This will be because Jason's RNG patch landed in mainline, but the
kernel version number won't get bumped (so compat.h can use it
properly) until 4.19 is released.
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird -
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 10/07/18 21:50, m...@farmwald.com wrote:
> Wireguard is 201806xx (25?) release - how I tell? Wg show doesn't
> list the version.
# cat /sys/module/wireguard/version
- --
Aaron Jones
-BEGIN PGP SIGNATURE-
Comment: Using
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Does this handle file descriptor 0 (unlikely, but perfectly valid) ?
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCgAdFiEEYKVBwe43zZh/jkxPivBzdIirMBIFAluT1qQACgkQivBzdIir
On 08/09/18 12:18, Julian Orth wrote:
> +static bool parse_transit_net(struct wgdevice *device, const char *arg)
> +{
> + /* U32 arg -> PID */
> + if (isdigit(*arg)) {
> + char *end;
> + unsigned long pid = strtoul(arg, , 10);
> + if (!*end && pid <=
On 08/09/18 12:18, Julian Orth wrote:
> +static bool parse_transit_net(struct wgdevice *device, const char *arg)
> +{
> + /* U32 arg -> PID */
> + if (isdigit(*arg)) {
> + char *end;
> + unsigned long pid = strtoul(arg, , 10);
> + if (!*end && pid <=
On 08/09/18 14:18, Julian Orth wrote:
> Even with clang's -Weverything I don't get a warning when I compile the
> following:
>
> #include
>
> int f(unsigned int i);
>
> int f(unsigned int i)
> {
> return i <= UINT32_MAX;
> }
Interesting... I don't either (gcc 8, clang 8). Perhaps I've
On 08/09/18 14:20, Julian Orth wrote:
> On 9/8/18 4:03 PM, Aaron Jones wrote:
>> Does this handle file descriptor 0 (unlikely, but perfectly valid) ?
>
> I believe so.
Ah, so it does; I misread the start of set_socket(). My apologies.
signature.asc
Description: OpenPGP di
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/04/18 14:32, bessonov.vic...@e-queo.com wrote:
> I've tried to run this instruction manually, result is still the
> same. The system runs CentOS 7 and properly updated.
Updated, yes; but not up to date. The version of iproute2 is too old.
cate AllowedIPs to a peer, it will remove it from the
previous peer, so the "order" is "most recently-configured".
> Is there any possibility to still use multiple routers like that?
Use multiple WireGuard interfaces.
- --
Aaron Jon
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 06/10/18 11:27, Evgeniy Ivanov wrote:
> Hi everybody,
>
> I’m able to generate the private keys pretty straightforward with
> any tool I like (eg: dd if=/dev/urandom bs=32 count=1 2>/dev/null |
> base64)
This is not sufficient, as documented on
eat piece of
> software! Indro Fedrigo
You cannot duplicate AllowedIPs. It forms WireGuard's internal routing
table. You're essentially asking for "If we have traffic to
192.168/16, send it to peer A, and also to peer B, and also to peer C,
and also to peer D".
That doesn't work.
- --
Aaron
ies as Ed25519
public keys, but they are in fact Curve25519 public keys; WireGuard
does not use an elliptic-curve signature scheme, but only
elliptic-curve Diffie-Hellman-Merkle key agreement.
- --
Aaron Jones
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https:
le-endian 32-bit encoding
is the following sequence of bytes: [ 0x01 0x00 0x00 0x00 ].
This is also the approach used for checking message types on the
receiving end, so packets whose reserved bytes are non-zero are already
discarded as being those of unknown types of message.
Regards,
Aaron Jones
Open
On 15/03/2021 13:31, Lonnie Abelbeck wrote:
> For giggles, I though this might be a clever solution:
> --
> [Peer]
> PublicKey =
> Endpoint = remote-vpn:51820
> AllowedIPs = 0.0.0.0/0, ::/0
>
> [Peer]
> PublicKey =
> Endpoint = 127.0.0.1:51820
> AllowedIPs = 192.168.0.0/16
> --
>
> I tested,
On 27/02/2021 17:16, Frank Carmickle wrote:
> Iordan,
>
> You say that it's possible to run a nested configuration on
> Linux and Macos with just a single interface each. Have you
> done a packet capture to prove that that is in fact what is
> happening? That doesn't seem like how it would act
-alives and periodic re-handshaking), plus periodic response packets
when traffic is only flowing one way (common if you run unidirectional
protocols over it; for example, UDP video streaming).
These extra packets are documented in the WireGuard whitepaper on the
website.
Regards,
Aaron Jones
On 12/10/2021 13:52, Gert Mertes wrote:
> Hi,
>
> My Windows client (0.4.11) will still sporadically send (and receive)
> keepalive packets over an idle tunnel, even though PersistentKeepalive
> is not set in the config of any peer in the tunnel. Explicitly setting
> it to 0 also has the same
On 05/10/2021 08:39, uxdwzco...@moenia.de wrote:
> using same port for all connections means, that for receiving encrypted
> packets every configured key must be tried, until the right one is
> found, or is this wrong?
Incorrect. The handshake establishes sender and receiver indexes; these
are
name" could be more specific
> to that. Because I had to struggle with the file name until I found
> out it is just a limitation of the length.
>
> Kind regards,
> Christoph
The network name determines the interface name, and on Linux, the
length of an interface name (e.g. "eth
32 matches
Mail list logo
