Re: Interface's Address is not saved when SaveConfig = true in config

[Jason A. Donenfeld]

Out of date iproute2?

Which distro? Version?

--
Sent from my telephone.

On Fri, Apr 20, 2018, 12:36 ST  wrote:

> Hello,
>
> I have
> ...
> Address = 192.168.4.1/24
> SaveConfig = true
> in wg0.conf
>
> 1. if I add a peer with `wg set wg0 peer ...` WG doesn't add it
> immediately to the wg0.conf file, only after I run `wg-quick down wg0`.
> Why not? What happens if the system crashes unexpectedly?... The peer
> will not be saved to the config file and the information will be lost.
>
>
> 2. once I run `wg-quick down wg0` I get:
>
> Option "-all" is unknown, try "ip -help".
> cat: /etc/resolvconf/run/interface/wg0: No such file or directory
> [#] wg showconf wg0
> sync: ignoring all arguments
> [#] ip link delete dev wg0
>
> Now the wg0.conf is enhanced with the peer details that was added
> through command line, but the Address = 192.168.4.1/24 disappears from
> the config. So running `wg-quick up wg0` again doesn't assigns IP to the
> wg0 interface... What's wrong?
>
> I'm using version:
> apt list wireguard
> wireguard/unstable,now 0.0.20180304-1 all [installed]
>
> Thank you!
>
>
> ___
> 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: Troubleshooting WireGuard connections

[Riccardo Berto]

On 2018-04-20 21:51, Jason A. Donenfeld wrote:

Could you let me know which kernel the non-working rapsis are running?
Also, have you tried this over different internet connections and
experienced the same thing?


I haven't tried this under different internet connection but one thing I 
must add is that the laptop is under the same local network of the 
raspberrys, they have the same gateway and the laptop works in 100% of 
the cases I tried it, both while pinging from the raspberrys and not.


Parallel execution on the raspberry of `tcpdump -vv -ni eth0 'port 
51820'` while pinging the server:


22:26:50.084184 IP (tos 0x88, ttl 64, id 45462, offset 0, flags [none], 
proto UDP (17), length 176)
192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf657 -> 
0xb3e7!] UDP, length 148
22:26:50.186665 IP (tos 0x0, ttl 48, id 31466, offset 0, flags [none], 
proto UDP (17), length 120)

server-ip.51820 > 192.168.1.155.51820: [udp sum ok] UDP, length 92
22:26:50.187667 IP (tos 0x0, ttl 64, id 45466, offset 0, flags [none], 
proto UDP (17), length 156)
192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x0316!] UDP, length 128
22:26:51.098777 IP (tos 0x0, ttl 64, id 45520, offset 0, flags [none], 
proto UDP (17), length 156)
192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x6049!] UDP, length 128
22:26:52.138753 IP (tos 0x0, ttl 64, id 45595, offset 0, flags [none], 
proto UDP (17), length 156)
192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x5608!] UDP, length 128
22:26:53.178751 IP (tos 0x0, ttl 64, id 45691, offset 0, flags [none], 
proto UDP (17), length 156)
192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x7eb3!] UDP, length 128
22:26:54.218760 IP (tos 0x0, ttl 64, id 45734, offset 0, flags [none], 
proto UDP (17), length 156)
192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x240c!] UDP, length 128
22:27:05.259544 IP (tos 0x88, ttl 64, id 46342, offset 0, flags [none], 
proto UDP (17), length 176)
192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf657 -> 
0x5a78!] UDP, length 148
22:27:05.359976 IP (tos 0x0, ttl 48, id 33703, offset 0, flags [none], 
proto UDP (17), length 120)

server-ip.51820 > 192.168.1.155.51820: [udp sum ok] UDP, length 92
22:27:05.360960 IP (tos 0x0, ttl 64, id 46348, offset 0, flags [none], 
proto UDP (17), length 60)
192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf5e3 -> 
0x7f66!] UDP, length 32


192.168.1.155 listed there is the static IP address of the raspberry pi 
in my local network.


Raspberry is running archlinuxarm with kernel: "Linux rpi3-two 
4.14.34-1-ARCH #1 SMP Mon Apr 16 19:15:19 UTC 2018 armv7l GNU/Linux"

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

Could you let me know which kernel the non-working rapsis are running?
Also, have you tried this over different internet connections and
experienced the same thing?
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

Oh, one thing that looks suspect is the bad UDP checksum. It appears
to be 0x92e3 every time, instead of the correct value (or 0).
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

Hi Riccardo,

Hmm, I'm really not quite sure from looking at that tcpdump. Are you
able to do one in parallel from the raspi? (Make sure both clocks are
correct with ntpd, so we can synchronize the timestamps.)

Alternatively, maybe just log onto IRC next week and we can debug this
in real time?

Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Using WG for transport security in a p2p network

[Jason A. Donenfeld]

Hey Ximin,

Nice to see that you're thinking through these issues in a concrete setting.

For a while I had some notions about allowing WireGuard to pop up
initiaton messages from unauthenticated peers to userspace for userspace to
then validate in one way or another asynchornously, followed by userspace
adding that peer's key to the list of peers (or not), and initiating the
handshake back the other way reusing the initial UDP port. This wouldn't add
that much complexity and I think it'd be fairly reliable. However, I've held
off on implementing it because I'm skepical that people would actually use it
in a way that makes sense. For example, in your case, you already have some
other aspect of the protocol which seeks to exchange this information; in
that case, doing the exchange there makes most sense, since you can morph and
change that for your particular requirements. In other words, I like the idea
you presented in your follow up email. Does that seem like a okay solution for
you? Or do you think you do have a compelling reason for adding the above
semantics?

Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Problems with IP

[Jason A. Donenfeld]

Hey Tim,

Oh, thanks for the info about RHEL 7.5. Perhaps the RPM then just
needs a warning, "WARNING: some functionality of wg-quick will be
unavailable in <7.5" or the like. We do this frequently in Gentoo
ebuilds, but I'm not sure whether or not it's something generally done
by RPMs. I'll defer to Joe on this.

Re:patch - I was thinking a patch for wg-quick rather than for
iproute2, but it looks like that's not entirely necessary now.

Jason
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Problems with IP

[Tim Sedlmeyer]

The recently released RHEL 7.5 ships with iproute2 4.11.0 so,
shouldn't have the problem.

If someone is interested in maintaining a patched version of 3.10.0
for prior RHEL versions the commit which added suppress_prefixlength
can be found at
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?h=v3.12.0=b1d0525f9cc3ef6fa7670ff3769828404cea31d4

It first appeared in version 3.12.0. The patch applies cleanly on top
of iproute 3.10.0. Whether it does on Redhat's patched version of
3.10.0 I don't know.

On Fri, Apr 20, 2018 at 11:56 AM, Jason A. Donenfeld  wrote:
> Hey Joe,
>
> Maybe we should patch the rpm for RHEL in some way? I can probably work
> around the old iproute2 by doing a different ip-rule(8) trick, if you'd be
> up for shipping that.
>
> Jason
>
> --
> Sent from my telephone.
>
> On Fri, Apr 20, 2018, 16:48 Aaron Jones  wrote:
>>
>> -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.
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJa2f2dAAoJEIrwc3SIqzASCVMP/A9tBO8Sbl1z9rGK0q9vjdyK
>> kMeFxKGVWqR4Xz8Sy9wfS+iKeXlBQxKukaZCTuSDr9WzsbpzvohYcE0FvGuDPZgf
>> G9TgrGK9NAPow6pIdCfgeIIUnBQQ5geLtnxXKdrr7yaXn2rB8KWi1nwM+NbenNnC
>> iJcPe7U9I+RzlDwESTHJMJJGR4hI8zbRSU4H3Nb2PEoYpizHUQuG56RGmOSDO08a
>> 1+uol4iBsR0EEBqyt3PUDjuSTjXSAm6G328pErC+aU6I9wP+FHsFUvfMnVd7GDG1
>> mJfVx2R8mLInlWX0gpL9YgelOC+/jIRDOeNKvdQAoqF3+7Tz+mT7J++/FLdQa3Sq
>> mgHaX+Tvjw6Rnl9KEYC9DqclmHuaoeAHtp7FGnxOXrSOE6fwVh/4BsfKKb7ntU0C
>> Wn0tRNrd/QagFm9Nyytm1g1IjoD/B+dXo9cT9p+bls/wBis4+jZZqJte40Kg1MaT
>> TlUeyLqVqXMWoUyqqn7Rit4E5ejgPbQpPywdKlJKCQrW4OoU+ualW+t+LUrluPAQ
>> ANQkenewaPmoEY4wLGJx02LeD8heYRGzVDkBMmohMiaSVgwibOfxcea7WiggcMNy
>> HICqRz1rCHIhDa0togIb2YPSiVsz+7rqW6shUgFabpDV3c7edfaZNcu5KwW5laCk
>> nY6A1S5hrgEOr3E8iPeK
>> =mFFE
>> -END PGP SIGNATURE-
>> ___
>> 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
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Problems with IP

[Jason A. Donenfeld]

Hey Joe,

Maybe we should patch the rpm for RHEL in some way? I can probably work
around the old iproute2 by doing a different ip-rule(8) trick, if you'd be
up for shipping that.

Jason

--
Sent from my telephone.

On Fri, Apr 20, 2018, 16:48 Aaron Jones  wrote:

> -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.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJa2f2dAAoJEIrwc3SIqzASCVMP/A9tBO8Sbl1z9rGK0q9vjdyK
> kMeFxKGVWqR4Xz8Sy9wfS+iKeXlBQxKukaZCTuSDr9WzsbpzvohYcE0FvGuDPZgf
> G9TgrGK9NAPow6pIdCfgeIIUnBQQ5geLtnxXKdrr7yaXn2rB8KWi1nwM+NbenNnC
> iJcPe7U9I+RzlDwESTHJMJJGR4hI8zbRSU4H3Nb2PEoYpizHUQuG56RGmOSDO08a
> 1+uol4iBsR0EEBqyt3PUDjuSTjXSAm6G328pErC+aU6I9wP+FHsFUvfMnVd7GDG1
> mJfVx2R8mLInlWX0gpL9YgelOC+/jIRDOeNKvdQAoqF3+7Tz+mT7J++/FLdQa3Sq
> mgHaX+Tvjw6Rnl9KEYC9DqclmHuaoeAHtp7FGnxOXrSOE6fwVh/4BsfKKb7ntU0C
> Wn0tRNrd/QagFm9Nyytm1g1IjoD/B+dXo9cT9p+bls/wBis4+jZZqJte40Kg1MaT
> TlUeyLqVqXMWoUyqqn7Rit4E5ejgPbQpPywdKlJKCQrW4OoU+ualW+t+LUrluPAQ
> ANQkenewaPmoEY4wLGJx02LeD8heYRGzVDkBMmohMiaSVgwibOfxcea7WiggcMNy
> HICqRz1rCHIhDa0togIb2YPSiVsz+7rqW6shUgFabpDV3c7edfaZNcu5KwW5laCk
> nY6A1S5hrgEOr3E8iPeK
> =mFFE
> -END PGP SIGNATURE-
> ___
> 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: Using WG for transport security in a p2p network

[Ximin Luo]

On Fri, Apr 20, 2018 at 5:20 PM, Ximin Luo  wrote:

> (reposting to the list, I'll learn one of these days..)
>
> On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld 
> wrote:
>
>> [..]
>>
>> Let me know if you have any more questions or ways in which I can help
>> you guys out with the p2p protocol.
>>
>>
> Hey, thanks for the reply. Another issue came up while I've been looking
> into this:
>
> At present, one has to manually add specific peers in order for WG to
> authenticate them. I was wondering what the options are for dynamic
> authentication, of peer keys that one doesn't know beforehand. The typical
> example would be a PAKE but for us it would be an alternative
> zero-knowledge proof that the initiator's key belongs to some allowed-set
> of peers wrt the responder's key, as defined by the rest of the protocol
> (I'm being vague because the details are TBD, actually).
>
> It would be nice to keep WG's current property of being able to
> authenticate a client on the first packet without requiring further
> communication. To reduce the DoS-potential of having to verify a complex zk
> proof, we can probably also include a proof-of-work linked to a recent
> global shared source of randomness (we have that in our protocol). So one
> way would be for WG to hook into a custom function that reads a custom
> certificate from the first incoming packet and say whether it passes the
> test.
>
> Alternatively we can listen on another socket, perform the custom check on
> incoming packets here, and then forward passing packets with our custom
> portion stripped out onto the local WG socket. Hopefully this would "just
> work" if the "from" address on the UDP packet is correct. However,
> initiating these would be tricky, we'd have to intercept the WG initial
> outgoing packet and rewrite it.
>
> Other suggestions would be much appreciated.
>
>
Here is another option that adds a half-round but is much simpler than
either of my suggestions above and doesn't involve modifying WG, so I think
I'll go with that. Might be useful for other people looking to do dynamic
auth on top of WG.

Peer A first authenticates and locates B via the parent protocol, adds B as
a WG peer, then:
 -> zk-proof "I am A, I am allowed to connect to you B"
Peer B verifies this proof and adds A as a WG peer, triggering the standard
WG protocol flow
 <- WG initiation, Noise_IKpsk2, etc
 ->
 <-, etc

Since it authorises the keys and WG stores these, it shouldn't be necessary
to re-run this after e.g a disconnection, WG should "just work" by itself.

X
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Using WG for transport security in a p2p network

[Ximin Luo]

(reposting to the list, I'll learn one of these days..)

On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld  wrote:

> [..]
>
> Let me know if you have any more questions or ways in which I can help
> you guys out with the p2p protocol.
>
>
Hey, thanks for the reply. Another issue came up while I've been looking
into this:

At present, one has to manually add specific peers in order for WG to
authenticate them. I was wondering what the options are for dynamic
authentication, of peer keys that one doesn't know beforehand. The typical
example would be a PAKE but for us it would be an alternative
zero-knowledge proof that the initiator's key belongs to some allowed-set
of peers wrt the responder's key, as defined by the rest of the protocol
(I'm being vague because the details are TBD, actually).

It would be nice to keep WG's current property of being able to
authenticate a client on the first packet without requiring further
communication. To reduce the DoS-potential of having to verify a complex zk
proof, we can probably also include a proof-of-work linked to a recent
global shared source of randomness (we have that in our protocol). So one
way would be for WG to hook into a custom function that reads a custom
certificate from the first incoming packet and say whether it passes the
test.

Alternatively we can listen on another socket, perform the custom check on
incoming packets here, and then forward passing packets with our custom
portion stripped out onto the local WG socket. Hopefully this would "just
work" if the "from" address on the UDP packet is correct. However,
initiating these would be tricky, we'd have to intercept the WG initial
outgoing packet and rewrite it.

Other suggestions would be much appreciated.

X
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Problems with IP

[Aaron Jones]

-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.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJa2f2dAAoJEIrwc3SIqzASCVMP/A9tBO8Sbl1z9rGK0q9vjdyK
kMeFxKGVWqR4Xz8Sy9wfS+iKeXlBQxKukaZCTuSDr9WzsbpzvohYcE0FvGuDPZgf
G9TgrGK9NAPow6pIdCfgeIIUnBQQ5geLtnxXKdrr7yaXn2rB8KWi1nwM+NbenNnC
iJcPe7U9I+RzlDwESTHJMJJGR4hI8zbRSU4H3Nb2PEoYpizHUQuG56RGmOSDO08a
1+uol4iBsR0EEBqyt3PUDjuSTjXSAm6G328pErC+aU6I9wP+FHsFUvfMnVd7GDG1
mJfVx2R8mLInlWX0gpL9YgelOC+/jIRDOeNKvdQAoqF3+7Tz+mT7J++/FLdQa3Sq
mgHaX+Tvjw6Rnl9KEYC9DqclmHuaoeAHtp7FGnxOXrSOE6fwVh/4BsfKKb7ntU0C
Wn0tRNrd/QagFm9Nyytm1g1IjoD/B+dXo9cT9p+bls/wBis4+jZZqJte40Kg1MaT
TlUeyLqVqXMWoUyqqn7Rit4E5ejgPbQpPywdKlJKCQrW4OoU+ualW+t+LUrluPAQ
ANQkenewaPmoEY4wLGJx02LeD8heYRGzVDkBMmohMiaSVgwibOfxcea7WiggcMNy
HICqRz1rCHIhDa0togIb2YPSiVsz+7rqW6shUgFabpDV3c7edfaZNcu5KwW5laCk
nY6A1S5hrgEOr3E8iPeK
=mFFE
-END PGP SIGNATURE-
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Problems with IP

[bessonov . victor]

Hello! While trying to bring wg0 interface up, I am getting this error:

[#] ip -4 rule add table main suppress_prefixlength 0
Error: argument "suppress_prefixlength" is wrong: Failed to parse rule
type

I've tried to run this instruction manually, result is still the same.
The system runs CentOS 7 and properly updated.

smime.p7s
Description: S/MIME cryptographic signature
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Troubleshooting WireGuard connections

[Riccardo Berto]

Sorry for the late answer, I've been busy with exams this week.

I updated WireGuard to the latest snapshot 20180420 on both server and 
peers.


I use unique key pairs for every host and I'm using the right 
privkey/pubkey combo, I just checked manually via the `wg pubkey` 
command.
I also tried removing all the peers but one Raspberry Pi, I'm still 
getting this weird output on the server from `tcpdump -vv -ni ens3 'port 
51820'`:


15:45:49.138470 IP (tos 0x0, ttl 52, id 27235, offset 0, flags [none], 
proto UDP (17), length 176)

raspberry-ip.51820 > server-ip.51820: [udp sum ok] UDP, length 148
15:45:49.138883 IP (tos 0x88, ttl 64, id 2728, offset 0, flags [none], 
proto UDP (17), length 120)
server-ip.51820 > raspberry-ip.51820: [bad udp cksum 0x92e3 -> 
0x0eae!] UDP, length 92
15:46:05.778398 IP (tos 0x0, ttl 52, id 27850, offset 0, flags [none], 
proto UDP (17), length 176)

raspberry-ip.51820 > server-ip.51820: [udp sum ok] UDP, length 148
15:46:05.778890 IP (tos 0x88, ttl 64, id 5807, offset 0, flags [none], 
proto UDP (17), length 120)
server-ip.51820 > raspberry-ip.51820: [bad udp cksum 0x92e3 -> 
0x85d0!] UDP, length 92
15:46:22.419043 IP (tos 0x0, ttl 52, id 28761, offset 0, flags [none], 
proto UDP (17), length 176)

raspberry-ip.51820 > server-ip.51820: [udp sum ok] UDP, length 148
15:46:22.419748 IP (tos 0x88, ttl 64, id 8596, offset 0, flags [none], 
proto UDP (17), length 120)
server-ip.51820 > raspberry-ip.51820: [bad udp cksum 0x92e3 -> 
0x6d8c!] UDP, length 92


Removing everything and simply adding the "always working" peer (my 
laptop) in the server config makes it working perfectly fine.

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: The case for anycast (contra move semantics for unicast AllowedIPs).

[Juliusz Chroboczek]

>> Recently, I've been mulling over move semantics and their
>> implication for WireGuard's support for anycast addressing.

Perhaps you could explain the purpose of having anycast support in a VPN
implementation?
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: PMTU Discovery Security Concerns

[Derek Fawcus]

On Mon, Apr 16, 2018 at 07:23:29AM +0200, Jason A. Donenfeld wrote:
> > See RFC4821, RFC8085 and
> > https://tools.ietf.org/html/draft-ietf-tsvwg-datagram-plpmtud-01
> > for more info about PLMTUD.
> >
> > https://datatracker.ietf.org/meeting/101/materials/slides-101-ipsecme-packetization-layer-path-mtu-discovery-01
> > has a quick overview of where IPsec stands with implementing it.
> 
> Thanks for these. I followed the rabbit hole, and found [1], which
> seems to be the current latest and greatest from the IPsec people.
> It's probes inside the control plane.

Using something based upon that UDP version of PLMTUD would seem to
be the correct approach, sending probe packets protected by the
encryption layer.

Rather than have it totally based upon the control layer, one could
use a data layer notification of decrypted packets arriving to
indicate that certain sizes have been received, then reflect those
back to the sender in a minimal encrypted ack packet.  i.e. something
similar to how solicited probe responses operate for IPv6 NDP.

Keep in mind that the PMTU may be different in the two directions.

DF
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Interface's Address is not saved when SaveConfig = true in config

[ST]

Hello,

I have 
...
Address = 192.168.4.1/24
SaveConfig = true
in wg0.conf

1. if I add a peer with `wg set wg0 peer ...` WG doesn't add it
immediately to the wg0.conf file, only after I run `wg-quick down wg0`.
Why not? What happens if the system crashes unexpectedly?... The peer
will not be saved to the config file and the information will be lost.


2. once I run `wg-quick down wg0` I get:

Option "-all" is unknown, try "ip -help".
cat: /etc/resolvconf/run/interface/wg0: No such file or directory
[#] wg showconf wg0
sync: ignoring all arguments
[#] ip link delete dev wg0

Now the wg0.conf is enhanced with the peer details that was added
through command line, but the Address = 192.168.4.1/24 disappears from
the config. So running `wg-quick up wg0` again doesn't assigns IP to the
wg0 interface... What's wrong?

I'm using version:
apt list wireguard
wireguard/unstable,now 0.0.20180304-1 all [installed]

Thank you!


___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: The case for anycast (contra move semantics for unicast AllowedIPs).

[Toke Høiland-Jørgensen]

George Walker  writes:

> Hi Jason, Juliusz, Toke, Dave, et. al.,
>
> A year ago we discussed Multicast addressing and the move semantics for
> allowedIPs.

Yeah, whatever happened to actually implementing that? :)

> Recently, I've been mulling over move semantics and their
> implication for WireGuard's support for anycast addressing.
>
> Unlike Multicast addresses, there are no designated address ranges for
> anycast: an anycast address is just a unicast address that's
> advertised in more than one place. As I understand it, the move
> semantics for allowedIPs preclude anycast addressing, as IP addresses
> can only be assigned to one peer at a time. This makes me wonder if it
> might be more correct to allow unicast allowedIPs to be assigned to
> more than one peer, treating them as anycast in that case.

That is not how anycasting works. You don't actually get more than one
path to an anycast address, and you don't duplicate any packets
(otherwise TCP would break, as you say). What anycast does is just that
it announced the same address in multiple places *at the control plane*,
and each router can then pick the closest path to that address and
install that one route in its data plane.

The AllowedIP configuration in WireGuard is the data plane configuration
(i.e., it corresponds to the kernel FIB). So supporting anycast at that
level doesn't make sense; you'll need to decide which peer gets your
"anycast" traffic. To the extent that anycast makes sense as a concept
at all on top of a VPN, you'd need to run some sort of control plane
(e.g., a routing protocol; there's a WireGuard GSOC that looks into
that) which would then configure appropriate AllowedIP configs into
wireguard.

> Also, if memory serves, move semantics account for a large proportion
> of the troubleshooting requests that show up on this list, suggesting
> to me that the status quo --elegant though it is!-- may not be
> especially intuitive.

This is probably a separate point that might be worth exploring further ;)


-Toke
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard