Re: Wireguard for FreeBSD without iflib

Hi Frank, On Wed, Mar 17, 2021 at 1:29 PM Frank Behrens wrote: > I read your messages from the last days in the freebsd lists. > In the version before removal from freebsd and in your current > repository at https://git.zx2c4.com/wireguard-freebsd/ I see a problem. > I can't loa

Wireguard for FreeBSD without iflib

Hello Jason, I read your messages from the last days in the freebsd lists. In the version before removal from freebsd and in your current repository at https://git.zx2c4.com/wireguard-freebsd/ I see a problem. I can't load the module, because I get the error: Mar 17 20:07:53 moon kernel

Re: Removing WireGuard Support From FreeBSD Base

even if we have phabricator for review. It looks like Kyle has gone ahead with the revert anyway, so development is now happening at: https://git.zx2c4.com/wireguard-freebsd/ And there are now regular snapshot releases: https://lists.zx2c4.com/pipermail/wireguard/2021-March/006518.html As for

[ANNOUNCE] WireGuard for FreeBSD snapshot 0.0.20210317 is available

Hi, An experimental snapshot, v0.0.20210317, of WireGuard for the FreeBSD kernel has been tagged in the git repository: https://git.zx2c4.com/wireguard-freebsd/ This is the most recent module as it existed before we thankfully pulled it from the 13.0 release in order to work on it more

Re: Removing WireGuard Support From FreeBSD Base

as one of the developers > involved. > > With regard to the original implementation, this will be my only > commentary on the matter. I'm a developer, and I'm passionate > about the work that I do- often to a fault. I've said some things that > I regret; the accusations that Sco

Re: Removing WireGuard Support From FreeBSD Base

to an operating system kernel is a bad idea. Yeah, when I saw the recent sudden work to get WireGuard into FreeBSD 13, I was excited but also nervous since it's been in beta/RC for a while, just a bit late to introduce important features. I think the current plan is sensible and will produce a

Re: Removing WireGuard Support From FreeBSD Base

will benefit from this type of process. > Maybe a good middle ground would be to take the existing code and put > it in a Wireguard branch. Those who wish to keep Wireguard out of > FreeBSD mainline have done so. FreeBSD users who wish to use Wireguard > can build the Wireguard branch.

Re: Removing WireGuard Support From FreeBSD Base

. In other words, we'll follow the tried and true formulation of: slow, careful coding + regular snapshots to receive testing and feedback. So, I'm quite happy there. And when it is ready, I'm confident it'll get a thorough review from FreeBSD core developers, which is terrific. More review ==> bet

Re: Removing WireGuard Support From FreeBSD Base

hould be clearly enumerated. Everything else is just chatter or noise. The move just looks like a bunch of bruised egos and sour grapes. Maybe a good middle ground would be to take the existing code and put it in a Wireguard branch. Those who wish to keep Wireguard out of FreeBSD mainline have done

Removing WireGuard Support From FreeBSD Base

to a fault. I've said some things that I regret; the accusations that Scott Long alluded to in an e-mail on FreeBSD mailing lists were indeed made by me, and his phrasing of what I said was much kinder than it could have been. These were mistakes, and I'm going to own that. However, my personal

Re: [ANNOUNCE] WireGuard for FreeBSD in development for 13.y – and a note of how we got here

the appropriate venue for discussion. I've also CC'd the FreeBSD Security Officer. I've responded to your email and its threats in line mailing-list style below: On Mon, Mar 15, 2021 at 6:08 PM Scott Long wrote: > What you and Kyle did was tell the world that there are a number of > ze

Re: [ANNOUNCE] WireGuard for FreeBSD in development for 13.y – and a note of how we got here

That's awesome! Thanks a lot for your hard work and dedication on wireguard. I really appreciate what you do including your willingness to work with non Linux OSes. Cheers, Reto

[ANNOUNCE] WireGuard for FreeBSD in development for 13.y – and a note of how we got here

Hi everybody, I’m pleased to announce that WireGuard now runs inside the FreeBSD kernel, with a driver called if_wg. It has full support of wg(8) and wg-quick(8) [5], as well as general integration into FreeBSD userland. Performance should be decent. The implementation in FreeBSD’s main branch

Re: FreeBSD/wireguard-tools

ion if the end result is being able to tap into the pre-existing knowledge pool available here. > I see the path forward for FreeBSD having a functional WireGuard > implementation as something like this: > > 1. We work out kinks in the kernel module crypto and state machine. I > need to

Re: FreeBSD/wireguard-tools

change. I see the path forward for FreeBSD having a functional WireGuard implementation as something like this: 1. We work out kinks in the kernel module crypto and state machine. I need to sync with Matt Dunwoodie on his findings there. Maybe we can send patches ourselves, but maybe it'd be best

FreeBSD/wireguard-tools

Hello! I'll start off with a slight overview of where we're at from a base system perspective: in November, an if_wg port from OpenBSD to FreeBSD landed in our development branch, along with updates to ifconfig(8) to manage it for the time being. We've committed a number of fixes and improvements

Re: [PATCH] FreeBSD default tun name patch

On Sun, Mar 7, 2021 at 9:45 AM kayrus wrote: > > This change allows to omit the tun interface name setting in FreeBSD. When > name > is not set, kernel automatically picks up the tun name and index. > --- > tun/tun_freebsd.go | 34 ++ >

Re: [PATCH] FreeBSD default tun name patch

Applied, thanks: https://git.zx2c4.com/wireguard-go/commit/?id=f4695db51c393f60ed9b8398b95b1f2013ad9b22

[PATCH] FreeBSD default tun name patch

This change allows to omit the tun interface name setting in FreeBSD. When name is not set, kernel automatically picks up the tun name and index. Signed-off-by: kayrus --- tun/tun_freebsd.go | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) diff --git

[PATCH] FreeBSD default tun name patch

This change allows to omit the tun interface name setting in FreeBSD. When name is not set, kernel automatically picks up the tun name and index. --- tun/tun_freebsd.go | 34 ++ 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/tun/tun_freebsd.go b

Re: FreeBSD/CARP: bind outgoing packets to virtual IP

with iptables. When it comes to FreeBSD we don't have any chance to rewrite packets in HA setups. Let's say you have unit1 with master IP 1.1.1.5 and unit2 with master IP 1.1.1.9 and a floating IP 1.1.1.7 which is only owned by the active unit. Without the option to bind the service to a fixed IP

FreeBSD/CARP: bind outgoing packets to virtual IP

Hi, for HA solutions within Linux it seems WireGuard has the ability to use fwmark to treat packet right with iptables. When it comes to FreeBSD we don't have any chance to rewrite packets in HA setups. Let's say you have unit1 with master IP 1.1.1.5 and unit2 with master IP 1.1.1.9

[PATCH 3/6] wg-quick: freebsd: add restart command

--- src/wg-quick/freebsd.bash | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/src/wg-quick/freebsd.bash b/src/wg-quick/freebsd.bash index e1ee67f..81c341b 100755 --- a/src/wg-quick/freebsd.bash +++ b/src/wg-quick/freebsd.bash @@ -387,7 +387,7 @@ execute_hooks() {

Re: FreeBSD wireguard wg-quick remote IP address assignment is incorrect

cmd ifconfig "$INTERFACE" inet "$1" "${1%%/*}" alias >>>> --- >>>>>if [[ -n $REMOTEADDRESS ]]; then >>>>> cmd ifconfig "$INTERFACE" inet "$1" "$REMOTEADDRESS" alias >>>>>e

Re: FreeBSD wireguard wg-quick remote IP address assignment is incorrect

RESS="$value"; continue ;; >> 175c177,181 >> < cmd ifconfig "$INTERFACE" inet "$1" "${1%%/*}" alias >> --- >>>if [[ -n $REMOTEADDRESS ]]; then >>> cmd ifconfig "$INTERFACE" inet "$1" "$REMOTEAD

Re: FreeBSD wireguard wg-quick remote IP address assignment is incorrect

if [[ -n $REMOTEADDRESS ]]; then > > cmd ifconfig "$INTERFACE" inet "$1" "$REMOTEADDRESS" alias > > else > > cmd ifconfig "$INTERFACE" inet "$1" "${1%%/*}" alias > > fi This is not a corre

Re: FreeBSD wireguard wg-quick remote IP address assignment is incorrect

update that bug report you filed? > > commit 2c6cabd73dfb23990c245250ef2e502bdb33d189 > Author: Jason A. Donenfeld > Date: Thu Feb 28 19:03:11 2019 +0100 > > wg-quick: freebsd: rebreak interface loopback, while fixing localhost > > The commit 7c833642 ("wg

Re: FreeBSD wireguard wg-quick remote IP address assignment is incorrect

We tried this already and it didn't work. See the below commit. Perhaps you can update that bug report you filed? commit 2c6cabd73dfb23990c245250ef2e502bdb33d189 Author: Jason A. Donenfeld Date: Thu Feb 28 19:03:11 2019 +0100 wg-quick: freebsd: rebreak interface loopback, while fixing

FreeBSD wireguard wg-quick remote IP address assignment is incorrect

t "$1" "127.0.0.1" alias Now local ping works. You can give any address I suppose since the ”remote address” of the ifconfig of a tun interface is not really used by wireguard. I also filed this as FreeBSD bug 244330. /Peter__

Freebsd Wireguard-go behavior

Hi, I’ve been using wireguard as a peer-to-peer VPN on linux for many years now (thanks Jason!) Recently I’ve been using wireguard-go on Freebsd. I noticed that there are a difference. I used to add an IP address to the wg interface on both sides, which is a good starting point to verify

Re: [PATCH] wg-quick: Linux and FreeBSD: Add support to search domain in wg-quick

W dniu 2020-01-28 o 13:52, Nico Schottelius pisze: > I second Mantas in this regard - don't bloat wg-quick, but a DNS > search path is pretty standard to be submitted by "a network". > > We are not talking dhcp boot options, even though NTP servers would > probably also make sense, if you see

Re: [PATCH] wg-quick: Linux and FreeBSD: Add support to search domain in wg-quick

Thanks for the feedback. As I'll use it with this patch and maybe it can solve the issue to anyone in the future, I share it on Github: https://github.com/rfrail3/misc/tree/master/wg-quick Regards, P.D: Congrats about the upstream sync! El 2020-01-28 13:52, Nico Schottelius escribió:

Re: [PATCH] wg-quick: Linux and FreeBSD: Add support to search domain in wg-quick

I second Mantas in this regard - don't bloat wg-quick, but a DNS search path is pretty standard to be submitted by "a network". We are not talking dhcp boot options, even though NTP servers would probably also make sense, if you see wireguard as providing a network. Best, Nico Mantas

Re: [PATCH] wg-quick: Linux and FreeBSD: Add support to search domain in wg-quick

That might be true, but IMHO the list of search domains doesn't fall under "specialized options" – it is even deployed via DHCP and similar mechanisms almost as commonly as the list of DNS resolvers themselves, so if a VPN client supports the latter then it makes sense to support both. On Tue,

Re: [PATCH] wg-quick: Linux and FreeBSD: Add support to search domain in wg-quick

I'm not so sure that we want to fill wg-quick(8) up with every dns nob... If you have specialized networking requirements, wg-quick(8) is probably not for you anyway. ___ WireGuard mailing list WireGuard@lists.zx2c4.com

[PATCH] wg-quick: Linux and FreeBSD: Add support to search domain in wg-quick

s runs in conjunction with DNS and only if that is +already set. Only available on Linux and FreeBSD. +.IP \(bu MTU \(em if not specified, the MTU is automatically determined from the endpoint addresses or the system default route, which is usually a sane choice. However, to manually specify an

Wireguard with disabled IPv6 under FreeBSD

Hello, I'm trying to setup wireguard server on FreeBSD which was built from ports. I have custom kernel build where I disabled IPv6 which I currently don't use at this VM. When I trying to start WIreguard I receive an error: # service wireguard start [#] wireguard-go wg0 INFO: (wg0) 2019/09/10

Re: Wireguard-go on FreeBSD - Not working until the interface (wg0) is set into promiscuous mode

I'll test it in the next couple of days and get back to you. Nate From: Jason A. Donenfeld Sent: Saturday, February 16, 2019 7:24 PM To: Nate Williams Cc: wireguard@lists.zx2c4.com Subject: Re: Wireguard-go on FreeBSD - Not working until the interface (wg0

Re: Wireguard-go on FreeBSD - Not working until the interface (wg0) is set into promiscuous mode

I'm not using wg-quick, so it's unlikely that this will fix things. Nate From: Jason A. Donenfeld Sent: Saturday, February 16, 2019 7:24 PM To: Nate Williams Cc: wireguard@lists.zx2c4.com Subject: Re: Wireguard-go on FreeBSD - Not working until the interface

Re: Wireguard-go on FreeBSD - Not working until the interface (wg0) is set into promiscuous mode

That's odd. Does this fix it for you? https://git.zx2c4.com/WireGuard/commit/?id=7c833642dfa342218602ab18e7091e86408d2982 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard

Wireguard-go on FreeBSD - Not working until the interface (wg0) is set into promiscuous mode

Setup: Client - Raspberry PI, running Wireguard native Server - FreeBSD box, running Wireguard-go Note, all of the computers involved in the test are running inside my local LAN, so there are no (active) firewalls involved at the moment, so any/all traffic is allowed between hosts. I setup

Re: WireGuard for FreeBSD

. > > Submitting ports here worked for me in the past: > > https://bugs.freebsd.org/bugzilla/query.cgi > > They are not picky usually. I am not using FreeBSD these days so. > Looks like things are underway and mostly done now, with the remaining blocker being me tagging a sna

Re: WireGuard for FreeBSD

nging a userspace implementation. > > So please, don't derail the current efforts in favor of an effort that > doesn't even exist at the moment. Submitting ports here worked for me in the past:   https://bugs.freebsd.org/bugzilla/query.cgi They are not pi

Re: WireGuard for FreeBSD

On Mon, May 21, 2018 at 11:35 PM, Jason A. Donenfeld wrote: > 2. wireguard-go > Runtime dependencies: none > Buildtime dependencies: gmake, go > Build: export GOPATH=$(pwd)/gopath; go get -d; gmake > Install: gmake PREFIX=/usr/local install > URL template: >

Re: WireGuard for FreeBSD

On Mon, May 21, 2018 at 5:35 PM, Jason A. Donenfeld <ja...@zx2c4.com> wrote: > [cross-posted to the WireGuard mailing list] > > Hello FreeBSD Ports List, > > I'm the author of WireGuard [1], a secure network tunnel protocol [2] > and a set of implementations of it. It

Re: WireGuard for FreeBSD

On Tue, May 22, 2018 at 2:33 AM, Outback Dingo <outbackdi...@gmail.com> wrote: > to be honest, while it sounds nice, i for one would prefer to see a > kernel module ported to FreeBSD instead of userland > second to that, building a freebsd port of it is not all that hard, > howev

WireGuard for FreeBSD

[cross-posted to the WireGuard mailing list] Hello FreeBSD Ports List, I'm the author of WireGuard [1], a secure network tunnel protocol [2] and a set of implementations of it. It was originally designed for the Linux kernel, but we're now beginning to have implementations for other platforms

Re: FreeBSD

Hi David, I know the pfSense people were interested in this for the FreeBSD kernel and taking a look. I'm not sure of their current project, but I'll reach out. Are you interested in implementing it too? Jason ___ WireGuard mailing list WireGuard

<    1   2