Running Wireguard on a switch

Hi, Nowadays, manageable switches often run Linux. Ben Cox managed to run wireguard on such a switch from Dell: https://blog.benjojo.co.uk/post/dell-switch-hacking He's not talking about performance (that was not the goal): the CPU on this switch looks like a low-end ARM so it's probably not

Re: Fragmentation on UDP layer possible?

On 13-08-18, Roman Mamedov wrote: > On Mon, 13 Aug 2018 02:53:44 +1000 > StarBrilliant wrote: > > > I know Wireguard can already do IP layer fragmentation. (Just set > > tunnel MTU >= 1441 then fragmentation will be turned on) > > Is that really expected to work? I tried setting MTU 9000 on

Re: Broadcast on wireguard

Hi, On 18-04-18, Christophe-Marie Duquesne wrote: > Hi list, > > Maybe the answer is obvious to some of you, but I don't quite > understand why wireguard does not support broadcasting, and I found no > clear explanation in the archive. In fact, this [1] seems to indicate > that implementing it

Re: Memleak with 0.0.20171221-5 on Debian stretch

On 18-02-18, Jason A. Donenfeld wrote: > > Nice, thanks! I'm looking forward to testing the next release then. > > Let me know if the problem goes away with the snapshot I just released. It does, thanks! I am now using 0.0.20180218-1 which does not have the memleak anymore. Baptiste

Re: Memleak with 0.0.20171221-5 on Debian stretch

On 12-02-18, Jason A. Donenfeld wrote: > Hey Baptiste, > > On Mon, Feb 12, 2018 at 8:42 AM, Baptiste Jonglez > <bapti...@bitsofnetworks.org> wrote: > > Actually, now that I talk about it, it's not 100% true: on this system, > > there is a second wireguard interf

Re: Memleak with 0.0.20171221-5 on Debian stretch

On 12-02-18, Baptiste Jonglez wrote: > Hi Jason, > > On 12-02-18, Jason A. Donenfeld wrote: > > Secondly, I'm wondering if you tend to do, "anything strange". For > > example -- are you setting up and taking down the device often in an > > automated way? Or

Re: Memleak with 0.0.20171221-5 on Debian stretch

Hi Jason, On 12-02-18, Jason A. Donenfeld wrote: > Secondly, I'm wondering if you tend to do, "anything strange". For > example -- are you setting up and taking down the device often in an > automated way? Or reconfiguring the interface (via wg(8), for example) > often in an automated way? Or is

Re: Memleak with 0.0.20171221-5 on Debian stretch

On 11-02-18, Daniel Kahn Gillmor wrote: > Hi Baptiste-- > > On Sun 2018-02-11 14:48:37 +0100, Baptiste Jonglez wrote: > > > On a x86_64 VM with quite a lot of Wireguard traffic (~300 GB per day), I > > am seeing a memory leak with wireguard 0.0.20171221-5. System is De

Memleak with 0.0.20171221-5 on Debian stretch

Hi, On a x86_64 VM with quite a lot of Wireguard traffic (~300 GB per day), I am seeing a memory leak with wireguard 0.0.20171221-5. System is Debian stretch, kernel 4.9.65-3+deb9u2, wireguard package from unstable. I have attached the memory usage reported by Munin over one month. The memleak

Re: Should I expect faster recovery after one side goes down

Hi, On 28-11-17, Bruno Wolff III wrote: > On Tue, Nov 28, 2017 at 00:44:13 -0600, > Bruno Wolff III wrote: > > > >I think the correct fix is to know if I reboot the router for testing > >something, I need to also restart wireguard to make sure it is sending > >data to the

Re: Fix Debian install guide on wireguard.com/install

u install it this way? > $ cat /etc/issue > Raspbian GNU/Linux 8 \n \l > > Best regards, > Adrian > > > On 15 Nov 2017, at 12:08, Baptiste Jonglez <bapti...@bitsofnetworks.org> > > wrote: > > > > Hi Daniel, Adrián, > > > > On 31-10

Re: Fix Debian install guide on wireguard.com/install

Hi Daniel, Adrián, On 31-10-17, Adrián Mihálko wrote: > There is a missing step in the Debian installation guide, you must import > GPG keys before you can add the new repo: Which version of Debian are you using? The installation instructions on https://www.wireguard.com/install/ are tested on

Re: Multihomed server issue

Hi Jason, On Thu, Aug 10, 2017 at 04:29:54PM +0200, Jason A. Donenfeld wrote: > 1. Packet from peer P arrives from src:A dst:B > 2. WireGuard records that it should contact P at src:B dst:A > 3. When sending an encrypted packet to P, it asks for which interface > to use for src:B dst:A. The

Debian-based configuration for wireguard

Hi, I wrote up some configuration I use for Wireguard on Debian: https://wiki.debian.org/Wireguard#Configuration_on_Debian The goal is to reuse functionalities from /etc/network/interfaces, which is quite natural on Debian. Simple use-cases like the point-to-point tunnel don't need

Indefinite queuing for unconnected peers (Was: problem wireguard + ospf + unconnected tunnels)

Hi, The current approach is to queue all outgoing packets for an indefinite amount of time when the peer is not connected or reachable. I think it does not make much sense, and leads to the kind of issue you mention here. The initial goal was probably to queue packets just long enough to be

Re: Installation instructions for Debian

unch. I think I had asked about this same thing > a while back, but somehow I got confused in the ensuing mailing list > thread and eventually I forgot about it. So I'm glad you've brought > this back up. I updated the install page with verbatim what you sent. > > Jason > > O

Re: Rebasing Wireguard's master branch

On Sat, May 13, 2017 at 09:10:40AM +0200, Baptiste Jonglez wrote: > Hi Jason, > > Could you please stop rebasing the master branch of the git repository? > It's really annoying (and possibly confusing) to obtain merge conflicts > while simply pulling the latest changes. There you

Performance of Wireguard on Infiniband 40G

Hi, Just for information, I did a quick test of Wireguard over a 40G Infiniband network, between two machines with a Xeon E5520. Using iperf (TCP mode) over the wireguard interface, performance was around 1.6 Gbit/s. In bidirectional mode (iperf -d), performance was 700 Mbit/s + 800 Mbit/s.

Rebasing Wireguard's master branch

Hi Jason, Could you please stop rebasing the master branch of the git repository? It's really annoying (and possibly confusing) to obtain merge conflicts while simply pulling the latest changes. If you want to rebase, please use feature branches or something similar. Thanks, Baptiste

TX counters not updated on wireguard interface

Hi, While trying 0.0.20170421-2 on Debian jessie, I noticed that the TX counters are not updated: $ ip -s link show 7: wg: mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default link/none RX: bytes packets errors dropped overrun mcast

Installation instructions for Debian

Hi Jason, Could you update the installation instructions for Debian [1]? Based on the discussion from a few months ago, and given that Wireguard now supports Jessie's 3.16 kernel, these instructions should be added: For Debian jessie or stretch: # echo "deb http://deb.debian.org/debian/

Release monitoring (Was: Wireguard added to Alpine Linux)

Hi Stuart, On Thu, Mar 02, 2017 at 09:49:53PM +, Stuart Cardall wrote: > To monitor releases @ Alpine we use https://release-monitoring.org/ - if > it doesn't pick up the changes I'll subscribe. Thanks for mentioning this, it's a nice tool! I started using it for other projects. By the

Re: [wireguard-devel ] traffic shapping

Hi Nicolas, For posterity, can you be more specific about how you solved your issue? You were simply missing traffic shaping support for IPv6 in your kernel? Which symbols were needed? Thanks, Baptiste On Wed, Mar 08, 2017 at 02:39:23PM +0100, Nicolas Prochazka wrote: > hello, > to close, it's

Re: [ wireguard-dev ] About configuring allowedip

On Thu, Feb 23, 2017 at 02:03:37PM +0100, Nicolas Prochazka wrote: > Hello, i'm trying to do this with wireguard, withtout success : > > peer1 ---> peer2 : config ok , works > peer3 ---> peer1 : config ok , works > peer3 --->peer1 ---> peer2 : not ok . > > I suspect allowed-ip configuration,

Re: (Unofficial) wireguard packages for Debian Stretch (testing)

On Tue, Feb 14, 2017 at 10:50:14AM -0500, Daniel Kahn Gillmor wrote: > on a similar system i'm using (stretch, with unstable available but > pinned low), i see only packages from stretch being installed (aside > from wireguard itself, clearly) > > 0 root@test:~# cat

Re: (Unofficial) wireguard packages for Debian Stretch (testing)

On Sat, Feb 11, 2017 at 03:48:59AM -0800, David Anderson wrote: > Okay, I've set up a Debian stable builder as well... However, Debian stable > has a 3.16 kernel, and wireguard-dkms requires >=3.18, so installation > fails. Assuming 3.18 is a hard lower-bound on kernel versions, it looks > like

Re: Maximum number of interfaces + Debug

On Wed, Jan 11, 2017 at 10:49:26PM +0100, Will van Gulik wrote: > Hi Baptiste, > > > On 11 Jan 2017, at 10:58, Baptiste Jonglez <bapti...@bitsofnetworks.org> > > wrote: > > > > Hi Will, > > > > > > There have been backwards-incompatibl

Re: [RFC] Handling multiple endpoints for a single peer

t react fast enough to new situations) and being overly enthusiastic (which means that you will react to the slightest insignificant change of your metric, impacting stability). What I proposed is based on happy eyeballs, see an excerpt of my first mail below: On Sun, Jan 08, 2017 at 11:41:17PM +01

Re: [RFC] Handling multiple endpoints for a single peer

On Sun, Jan 08, 2017 at 08:37:55PM -0600, Samuel Holland wrote: > Hello, > > On 01/08/17 16:49, Jason A. Donenfeld wrote: > >However, this doesn't shine any light on the hardest problem: how to > >update the list of addresses in a memory-bounded fashion. Right now, > >if you receive an encrypted

Re: Multiple Endpoints

Hi Jason, On Sun, Jan 08, 2017 at 11:18:01PM +0100, Jason A. Donenfeld wrote: > > So, if a client is connected to the server and the server changes its IP > > address, the client will keep trying to use the old IP address forever. > > No. If the server sends a packet to the client using the same

[RFC] Handling multiple endpoints for a single peer

Hi, Here is a proposal for handling multiple endpoints for a single Wireguard peer. This includes handling dual-stack peers (IPv4 and IPv6) but is more general. This is something I had discussed with Jason at the beginning of the project, but we agreed at the time that it was too early for the

Re: openwrt route_allowed_ips is inprecise

On Sun, Dec 18, 2016 at 09:14:18PM +0100, Jason A. Donenfeld wrote: > The way it should be done is described in wg-config: > > https://git.zx2c4.com/WireGuard/tree/contrib/examples/wg-config/wg-config#n130 > > if [[ $AUTO_ROUTE -eq 1 ]]; then > for i in $(wg show "$INTERFACE"

[WireGuard] Is nf_conntrack really needed?

Hi, I stumbled upon a build error on LEDE, which was caused by a missing dependency to nf-conntrack (and possibly nf-conntrack6). I see that NF_CONNTRACK is used only at one place in device.c, and it is inconditionally required since 3106d632de ("build system: revamp building and

Re: [WireGuard] mips32 crash

On Mon, Nov 07, 2016 at 03:06:02AM +0100, Jason A. Donenfeld wrote: > Not a lot of participation from the LEDE package maintainer Well, I only saw one mail from the reporter, so it's difficult to understand your discussion. I haven't run-tested wireguard on an actual router in a while, so there

Re: [WireGuard] News about MIPS and ARM optimized code?

Nice work! I had tried to write chacha20_generic_block in MIPS assembly, but I got confused with endianness issues and the code didn't work in the end. Is your code available somewhere? I'd be happy to test on a variety of MIPS routers. On Fri, Sep 09, 2016 at 01:46:11PM +, René van Dorst

Re: [WireGuard] Using wireguard link as a proxy?

On Fri, Jul 22, 2016 at 04:09:13AM -0500, Bruno Wolff III wrote: > On Fri, Jul 22, 2016 at 10:18:21 +0200, > Baptiste Jonglez <bapti...@bitsofnetworks.org> wrote: > > > >Yes, the notion of "immediate next destinaton" does not make sense for > >Wireguard.