Re: Sharing peer data

Thanks Jason, Yes, something very similar to tinc. I imagine having two or more static/known peers (redundancy) configured on every node. Once connected, they discover the others. It's good to know there is a GSoC for something like it. -- Luiz Angelo Daros de Luca luizl...@gmail.com __

Re: Troubleshooting WireGuard connections

Hi Riccardo, That's a confusing result. The tcpdump also shows two sequences of completed handshakes happening, about 7 seconds apart. It might be best in the end to hop onto IRC next week, and we can debug this in real time. But based on the erratic behavior, my only guess remaining is that you'v

Re: Sharing peer data

Hi Luiz, You could indeed arrange for something like this, either directly -- if both IPs are accessible or if A is able to punch a hole -- or relayed, if you can't establish a direct session. This is similar to what Tinc does. Namely, this falls in the category of, "making a full mesh from a part

Re: Mixed MTU hosts on a network

Hey Roman, I've just tried a few ways of replicating your setup, and I can't seem to reproduce the bug, either with the new code or old. The results you mention are surprising too, since WireGuard or not, TCP is supposed to negotiate the lowest common MSS. I wonder if some strange iptables rules a

Sharing peer data

Hello, In a setup node A <> node B, node A <> node C, C might talk to B passing through A. Would it be possible that A could share B and C info (ip and pubkey) in other to them to talk to each other directly? It would be similar to ip redirect. Node A must be trusted by both for that. Regards, --

Re: Policy-based routing

Hi Jason, Thanks for your input. I agree with you. But I could have the peers based on table routing and marking packets, were all the traffic (0.0.0.0/0) would be routed based on the prior conditions (tables and marking). I'm doing one interface per peer right now, but I thought it could be

Re: Using WG for transport security in a p2p network

On 14.04.2018 18:01, Bruno Wolff III wrote: > On Thu, Apr 05, 2018 at 09:13:03 +0200, >  Matthias Urlichs wrote: >> Hi, >>> >>> Another option would be to run insecure QUIC or SCTP on top of >>> WireGuard, >> You cannot run SCTP on the In

Re: Using WG for transport security in a p2p network

On Thu, Apr 05, 2018 at 09:13:03 +0200, Matthias Urlichs wrote: Hi, Another option would be to run insecure QUIC or SCTP on top of WireGuard, You cannot run SCTP on the Internet anyway. Too many routers block anything that's not TCP

Re: Mixed MTU hosts on a network

On Sat, 14 Apr 2018 16:45:32 +0200 "Jason A. Donenfeld" wrote: > In this case, WireGuard seems to be doing the right thing. Think you > could come up with some minimal test that exhibits the behavior you're > seeing? I now remember in more detail what was the problem. It was not with MTU 1412 on

Re: Mixed MTU hosts on a network

Hi Roman, That's strange; I'm unable to reproduce what you've described: [+] NS1: ip link set wg0 mtu 1412 [+] NS2: ip link set wg0 mtu 1412 [+] NS1: wg set wg0 peer QXloTaPOwUTzqFElVLSD0vBc4sxjyoKtPBSaTkZHokY= endpoint 127.0.0.1:2 [+] NS2: wg set wg0 peer X0p7+UWc4wjaAmT73xAEuXLY80I6Gv8vTg6KwFHC

Re: Mixed MTU hosts on a network

On Sat, 14 Apr 2018 16:15:07 +0200 "Jason A. Donenfeld" wrote: > Hi Roman, > > I answered this in my first email to you, which perhaps got lost in > the mix of emails, so I'll quote the relevant part: > > > 2) When we pad the packet payload. In this case, we pad it to the > > nearest multiple o

Re: Mixed MTU hosts on a network

Hi Roman, I answered this in my first email to you, which perhaps got lost in the mix of emails, so I'll quote the relevant part: > 2) When we pad the packet payload. In this case, we pad it to the > nearest multiple of 16, but we don't let it exceed the device MTU. > This is skb_padding in send.

Re: Mixed MTU hosts on a network

On Sat, 14 Apr 2018 15:16:56 +0200 "Jason A. Donenfeld" wrote: > Hi Roman, > > This commit should fix it. It now has a unit test too so that we don't > hit this issue again. Thanks for reporting it in such detail. > > https://git.zx2c4.com/WireGuard/commit/?id=a88a067d5477f877003d3703bb3b95cb4e

Re: Mixed MTU hosts on a network

Hi Roman, This commit should fix it. It now has a unit test too so that we don't hit this issue again. Thanks for reporting it in such detail. https://git.zx2c4.com/WireGuard/commit/?id=a88a067d5477f877003d3703bb3b95cb4e94bc46 Let me know if that fixes it on your end. Jason

Re: wg-ip, a tool to assign automatic ip addresses to wireguard interfaces

Hi, > One of the things we'll be investigating is whether it's best to > derive a v6 address from a public key or whether it's best to make > these separate/unrelated and share them alongside the public key. > While the former is much more elegant, a significant problem is > choosing the right beh

Re: Include directive to support "conf.d/*" and the like

On Sat, 14 Apr 2018 03:47:57 +0200 "Jason A. Donenfeld" wrote: > Hi Roman, > > This also came up in another thread I was replying to earlier tonight. > While one way indeed is to have an 'include' directive, it seems > simple enough to just do something like: > > $ wg setconf wg0 <(cat /etc/wir

Re: wg-ip, a tool to assign automatic ip addresses to wireguard interfaces

Hi Jason, Sure, I would be happy to help! @Martin: based on your name and some quick googling, I assume you are German. If you are in Munich, let me know, we could meet and discuss about your gsoc topic in real life. Best, Christophe-Marie On Sat, Apr 14, 2018, 00:25 Jason A. Donenfeld wrote:

Re: Troubleshooting WireGuard connections

On 2018-04-14 03:26, Jason A. Donenfeld wrote: Hi Riccardo, Based on those tcpdump timestamps, it looks like the handshake response happens nearly immediately after the handshake initiation. Yet from your description, it appears only after many moments. In my experience, tcpdump blocks like this