On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs
writes:
>
>> Can anybody think of problems with this solution?
>
> Well, the possibility of DOS if you set the counter too high,
Correct me please, but skipping even many counter values should not be a
problem at all. So do you
Hi Jason,
thanks for your hard work!
On Wed, 2018-05-16 at 00:54 +0200, Jason A. Donenfeld wrote:
> [NEW] WireGuard for Android
> ---
> You can download the app from the Play Store or from F-Droid. It supports
> adding wg-quick(8)-style .conf files or .zips of them. The ap
On 15.05.2018 22:49, Kalin KOZHUHAROV wrote:
> [1] Can anyone point me to the piece in code that shows that
> precision? In other words, how far apart can 2 peers' clocks be and
> still connect.
Infinite.
Seriously. The timestamp field is essentially a counter. It just counts
up in rather large
On 16.05.2018 09:10, Stefan Tatschner wrote:
> How can I debug this further?
Check the output of "ip rule".
--
-- Matthias Urlichs
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
> > On 16.05.2018 09:10, Stefan Tatschner wrote:
> > How can I debug this further?
>
> Check the output of "ip rule".
As a user I can't read anything useful out of this, since I don't known how
wireguard android sets its fwmarks, etc. But here it is:
lux:/ # ip rule
0: from all lookup local
Axel Neumann writes:
> On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs
> writes:
>>
>>> Can anybody think of problems with this solution?
>>
>> Well, the possibility of DOS if you set the counter too high,
>
> Correct me please, but skipping even many counter values should n
On 16.05.2018 11:38, Toke Høiland-Jørgensen wrote:
> No I meant DOS if you fail to save state properly. I.e., I send seqno
> 10, lose my state, reboot, and re-initialise to seqno 100.
So don't do that then. Your saved state needs to be substantially higher
than any seqno you could possibly send
Am 16. Mai 2018 11:38:23 MESZ schrieb "Toke Høiland-Jørgensen" :
>Axel Neumann writes:
>
>> On 13.05.2018 14:37, Toke Høiland-Jørgensen wrote:> Matthias Urlichs
>> writes:
>>>
Can anybody think of problems with this solution?
>>>
>>> Well, the possibility of DOS if you set the counter too
Actually, in wg0.conf the private key is defined in clear text. Which allows
dump of physical disk to grab it
and to fake this client.
Wouldn't it be safer, to cipher the private key somehow ?
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
http
On Wed, 16 May 2018 05:22:05 + (UTC)
reiner otto wrote:
> Then individual keys for the clients, sigh.
>
> Which leads to next question:
> When adding a new client to the servers wg0.conf,
> does it require a restart of wg, _OR_ is it safe to simply "edit" wg0.conf,
> adding the clients info
On 16.05.2018 14:53, reiner otto wrote:
> Actually, in wg0.conf the private key is defined in clear text. Which allows
> dump of physical disk to grab it
> and to fake this client.
So? If you have physical access to the peer's (unencrypted) disk you can
do anything. Security is over.
> Wouldn't it
Hi,
On 16/05/18 22:06, Matthias Urlichs wrote:
> On 16.05.2018 14:53, reiner otto wrote:
>> Actually, in wg0.conf the private key is defined in clear text. Which allows
>> dump of physical disk to grab it
>> and to fake this client.
> So? If you have physical access to the peer's (unencrypted) di
Hi all,
So - I don't know if it's me being *thick* or wg-quick isn't supposed to do
this, but:
I have a wireguard config on my Macbook with addresses 10.3.0.5/31 &
fd10::10:3:41/127, other endpoint is .4 and :40.
Running wg-quick up wg-x works fine - pinging the v4 of the other side
doesn't
Am 15. Mai 2018 22:49:15 MESZ schrieb Kalin KOZHUHAROV :
>On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter
>> Using NTP is not a viable solution for a distributed mesh network.
>What
>> if the Internet is only accesible via WG, or what if the network is
>not
>> connected to the Internet at all
> $20 would increase the HW cost of many typical community-networks (CN)
deployments significantly.
This seems unlikely. In most cases, $20 is notably less than the cost of a
single node.
> Plus requiering more knowledge, maintenence, and power supply for
sometimes solar-powered setups... no USB.
Hello Axel,
I may have not been clear in my last response, it was to be taken in
the context of the whole thread...
On Wed, May 16, 2018 at 9:32 PM, Axel Neumann wrote:
>
>
> Am 15. Mai 2018 22:49:15 MESZ schrieb Kalin KOZHUHAROV :
>>On Tue, May 15, 2018 at 10:21 PM, Devan Carpenter
>
>>> Using
Hi all,
If I'm not mistaken replay attacks are checked here [1] and only
compare integers with no reference to local time of the receiving node.
The sending nodes timestamp is generated via tai64n_now [2][3]. From my
understanding this function could simply be changed to a auto increased
cou
On Thu, 17 May 2018 12:40:55 +0900
Paul wrote:
> For me it looks like a problem solvable in software (as done for the
> BMX routing protocol). Why even bother to get hardware involved?
Personally I am puzzled this is even an issue in WG. Not a single other VPN
protocol mandates every node to ke
On 17.05.2018 07:03, Roman Mamedov wrote:
> Personally I am puzzled this is even an issue in WG. Not a single other VPN
> protocol mandates every node to keep a monotonically increasing counter,
> including even over reboots.
Wireguard's connection setup is a whole lot simpler than most other
prot
19 matches
Mail list logo