rwp: i found an other pair of bug reports for a problem with FreeBSD dns stub resolver and there hasn't been any change in years despite a patch

the problem is you can use a link-local address as nameserver in resolv.conf

rtsold will correctly install the entry via resolvconf

but the DNS stub resolver will consider it invalid syntax for an ip address and ignore the line

the issue has even been brought up upstream on github by someone else

it happens *sigh*

Do you guys know if there are any differences between the 'wireguard-tools' package and the 'wireguard-go' package, other than one being written in go?

oh wait, it seems I might not even need to install either... I will now go RTFM

crest, It feels strange to be using a link-local address for a resolver when the loopback device is always available and more well used.

That's probably also why that has been languishing. Using a LL address is not really needed. It has a typically used alternative that is always available.

rwp: its kind-ish could have sense if configured per interface basis... but taking on mind some isp routers using fe:: pool for ipv6 only nat64 mode setups for router... linklocal for resolver not sounfs as crazy...

I guess we don't know if that link-local address is an IPv6 fe02::/16 address or an IPv4 169.254.0.0/16 address. But either way it feels strange. Because using DNS to me implies that one is connected to the larger network.

But I could see someone arguing the point that a system could be set up and configured on an isolated LAN without connection to the larger network. And then, strange as that might seem, set up DNS locally.

I am imagining a small cluster on a dogsled radar mapping the land under the ice in Antarctica.

you don't even need to imagine that far. airgapped networks exist for e.g. classified work

as in, airgapped from the broader Internet

Oh sure. I have set up airgapped systems myself. But I always used 10.*/8 networking in that case with everything static because allowing dynamic addressing seemed counter to the security of a private LAN.

the ones I'm talking about still have DNS & DHCP and so forth

There is no problem setting up DNS on a private LAN with say a 10.*/8 network. And DHCP too for that matter but that seems to me to be counter to the philosophy there. But there isn't anything hard about it.

just wanted to drop by and say my recently rebuilt FreeBSD 15.0 desktop is a nice running machine! using a Gnome 47 desktop. Still on Xorg. Seems to be quite good at this moment.

nulltaz: the wireguard-go port is a wireguard userspace implementation in go

it uses a tun device as network interface

that makes it portable, but slow

wireguard-tools is the wg cli tool

the wg command has been imported into freebsd base

and freebsd has its own in kernel implementation

is wireguard possible to get running in a Jail? I've been successful with bhyve VMs, and regular proxmox VMs, etc. but yea... so far no go on a jail fo rme.

what part do you want in the jail? you can create a vnet jail and give it the wg interface for networking (I guess that is what you want to do)

oh, right. if you do it with vnet, yeah, it works. I just didn't want to use vnet - stability issues in the past, and usually need 2 nics to prevent network 'blinking' on the host.

Laidback_01: yes if you use vnet jails

you could also have the host manage the wireguard interface and put alias addresses on it, but thats probably not what you're asking for

woo, just set up vnet jails with one person's method - creating an epair, bridging one end of the epair with another interface, passing other end into jail

epairs were new to me, maybe because I'd never heard of the exact thing from Linux-land

seems like the equivalent in linux would be veth

oh, yeah, that sounds right

Hey quick question. Since WireGuard support is included at the kernel level (wg interfaces), then what is the point of installing the wireguard-tools package?

nulltaz: This supplies the main userspace tooling for using and configuring

WireGuard tunnels, including the wg(8) and wg-quick(8) utilities.

But I’m pretty sure I configured the wg interface and generated the keys without that package

and are you also connect without these?

then you don't need them, for me i couldn't use wg without these tools

esp. wg-quick makes it easier

wg-quick makes it easier if your setup matches what wg-quick assumes you want to do

i see, im not that experienced

I just followed the steps in the “Command-line interface” section of this page on the official WireGuard site (using ifconfig instead of ip for the first two steps)

Seems like there’s barely any config. Generate keys on the client and server, and then set preferences on the wg interface using ‘wg setconf’

If it’s that simple, there’s no need for wireguard-tools ?

I just can’t figure out what wireguard-tools is for lol

wireguard's included in the kernel? was this a recent change?

2022?

wireguard's in the kernel?

like by default or you have to add it?

maybe I read news.ycombinator.com/item?id=33381949 and it served only to confuse me

i honestly think wireguard is useless since there are other protocols that do better

why'd you re-invent the wheel?

in my usage of it I've quite liked it

nulltaz: well, wg-quick combines those three commands, lets you have the IP in the config file and if you have the VPN for all connections then DNS= in the config sets resolvconf up correctly, if you don't match that expectation then the nameserver set there will be configured as only nameserver for the system, so you would have to work with PostUp/PreDown

nimaje, ah, that makes sense. ty

scottpedia: do you have examples? especially better in the performance goal of wireguard would be interesting

ipsec

how’s that better?

IPsec VTI interface via if_ipsec

SomeVisitor: ipsec can make use of hardware crypto acceleration

libreswan is built into the kernel so there is the performance increase

e.g. AES-GCM via AESNI and PMUL instructions

scottpedia: nope

???

so does wirguard, or am I wrong, crest?

the ipsec kernel code isn't part of libreswan (at least on FreeBSD)

the interface between the IKE daemon (strongswan, libreswan, iked, whatever) and the kernel happens via PFKEYv2 on FreeBSD

maybe I used the wrong terminology but I think it's loaded into the kernel? or what?

SomeVisitor: no because wireguard uses a single ciphersuite that hardcoded into the protocol

enlighten me then

for wireguard traffic encryption that's chacha20 + poly1305

chacha20 is a fast cipher for software crypto

cause I once asked if libreswan can be statically linked and compiled

and isn't terribly slow anywhere

they say it's possible but'd lose all performance bonus due to being out of the kernel

I pretty much max out my network speeds with wireguard without much cpu load

where as AES-GCM can't that fast in pure software if you want to protect against timing sidechannels

but on any x86 cpu released in the last ~15 years there are special instructions to make AES and GCM faster

ipsec because of its flexibility can make use of the exact cipher combination accelerated by common hardware features

ipsec is widely used across the industry

the crypto isn't specific to ipsec

often in peering between campus networks

most things are widely used before they become superseded ;)

the aesni + pmul instructions can be used for other protocols that use the same ciphers e.g. TLS oder SSH

but wireguard has a single cipher written into the specification so it can't take advantage of these hardware features

if you use IPsec on FreeBSD there is a kernel datapath for it which daemons like strongswan can configure

it works like this

the daemon configures a policy

the kernel matches traffic against the policy

it’s easy to configure without the chance to shot into foot. So it has it place, even if other software is more flexible I think

on a match the kernel checks if it has a session key to use

if not it buffers the packet and give the daemon a chance to establish a new session

crest: i'd be great if you can walk me through this in detail. I couldn't seem to figure it out myself for a long time now.

the general idea is spelled out in the PFKEYv2 RFC

IPsec has a lot of really annoying historical baggage that you can't hide from if you use it

it was designed by a committee in 90s

so everyone brought their own ideas an instead of selecting only the good ones they agreed to optionally put in a whole lot of duplicated crap

also back than many operating systems had fairly primitive network stacks

so the designers (ab-)used IPsec to force certain features into any network stack that wanted to call itself IPsec capable

e.g. the whole IPsec transport vs tunnel (vs virtual interface) mess

also they didn't really knew how IPsec would be used

there was this confused notion of (opportunistic) traffic encryption

crest: any study resources to recommend?

»IPsec was a great disappointment to us.« (Ferguson, Schneier) [scnr]

good question. i don't have a single handy source to give you.

how'd you know so much? crest

some of it is in old mailing list archives, other spread over a dozen books etc.

scottpedia: i had to make ipsec work when the only alternative was openvpn

okay?

and by make work i mean between different implementations

that sounds like how you deal with AWS VPC

which I worked with in peering

kind of hard to deal with

that's easy because you have a single well known peer configuration 1000s of people used before you

okay

also the still actively used stuff is just a small subset of the crap that used to exist in the wild

wat you think of libreswan?

if i have to use ipsec on freebsd i normally use strongswan

what's the main difference

and before that i used racoon *shudder*

i can't tell you because i never had reason do give libreswan a chance

iirc one is a fork of the other

okay alright

'd be great if I can consult you in the future regarding any ipsec-related questions crest

you seem to be extra-knowledgeable

scottpedia: you can try, but my recommendation for new deployments would be to use WireGuard unless you know why you need IPsec

ok thx for the advice

it's duly noted

and if you need something with easy to manage clients maybe give openvpn a chance, because they have added data channel offloading on FreeBSD 14 and recent Linux versions

which does what the name implies: offload the traffic into the kernel for supported configurations

okay. i always used openvpn to connect to VPS's subnet for raw console access

it does not change the traffic so the peer doesn't know the difference

it seems to be more widely adopted by the industry lately

iirc OpenVPN DCO only supports uncompressed Layer 3 client-server mode

okay

but for stuff like IPMI access WireGuard is more than fast enough

okay

it feels like a new player so i had to be cautious

a product of the 2020s

it's fairly new, but it took advantage of decades of other peoples mistakes

to learn what a vpn needs to be and only add what is easy to add

okay that sounds reassuring

anyways gotta go. it's great talking to you.

e.g. a formally verified handshake protocol instead of hacking some custom crypto

the slightly slower crypto is also one that is fast enough on every imaginable CPU

so it doesn't depend on special hardware to get good performance

at the cost of not getting the very best performance if you have special hardware available

the real uservisible difference is how many fewer settings there are

a wireguard configuration is normally ~10 lines

while ipsec configuration can easily grow to 100 lines

plus dealing with a X.509 PKI to solve problems >98% of the users won't have

with users defined as the poor bloke that has to make it work

as we are on the topic of vpns, I try to configure openvpn to start a jail with the tun device it creates and manage it via scripts (that part works), but on the server side (which I don't control) are multiple servers that push me stuff like IP, gateway and DNS configuration, my problem is that on reconnects sometimes openvpn decides that it has to destroy the tun device for some reason (my guess

is the pushed IP Address changed), I already set persist-tun ifconfig-noexec and route-noexec, but they don't seem to help, any ideas how to fix that?

hm, maybe I can use another script around openvpn with --mktun and --rmtun to workaround, but I still have no idea why openvpn thinks it has to recreate the tun device

ls

. ..

ls ..

. ..

I have a somewhat dated rhat8 box. . . and I need unison installed it, for which there does seem to be a package.

So I downloaded the latest tarball, un-tar'd it and ran make.

First it bitched because there was no ocaml installed. . . so I installed the ocaml.x86_64 v4.07.0-3.el8 package and re-ran make: bpa.st/P7TQ

Any ideas on how to proceed?

FreeBSD 15... typing "pkg" can't find a suitable version to install the pkg program on the system...?

good day #freebsd

!inspire

The mind that turns ever outward Will have no end to craving. Only the mind turned inward Will find a still-point of peace. -Ming-Dao Deng [zenquotes.io]

is there a supported method to create 13.x compatible zpools in freebsd 14.x and 15.x?

zerotime: Yes. Look at the -o compatibility= options.

zerotime: In particular look in /usr/share/zfs/compatibility.d/

I use, for instance, openzfs-2.2 as it covers all my systems here, FreeBSD and Linux. I'll nudge it up when possible.

so whats the requirements for a poudriere build jail

which is created by poudriere

say if I make installworld to create a jail from src, how does this differ from poudriere?

i assume /usr/ports is a requirement within the poudriere jail too