NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: starting off with wireguard



Taylor R Campbell <riastradh%NetBSD.org@localhost> writes:

>> From: Greg Troxel <gdt%lexort.com@localhost>
>> Date: Wed, 18 Mar 2026 19:30:34 -0400
>> 
>> I find that "pseudo-device wg" is required in the kernel (no surprise!)
>> but am surprised by:
>> 
>>    - it's not available as a module in 10 or 11
>>    - it's not in GENERIC for amd64 in 10 or 11
>>    - it's not in GENERIC for evbarm anything in 10 or 11
>> 
>> Is this a clue that?
>> 
>>    - I'm confused.
>>    - wg is really not baked (the "EXPERIMENTAL" label) and people
>>      believe it is flaky or likely does not provide the confidentiality
>>      one expects.
>>    - wg is believed fine and many use it but for some good reason people
>>      think you should have to build a kernel.
>>    - wg is believed fine and nobody has gotten around to adding it.
>
> wg(4) is available as a module `if_wg' on all ports that have modules.

I was looking for wg, not if_wg :-) because the kernel line is
"pseudo_device wg" and I haven't been paying attention.  But indeed my
builds have if_wg.
>
> As experimental new code, it was originally intentionally not enabled
> in any GENERIC kernel by default, and it was supposed to require an
> explicit step to `modload if_wg' or put if_wg in /etc/modules.conf
> (except for the part where I forgot that module autoloading is a thing
> and never got around to blocking module autoload of if_wg.kmod).

and the part where the man page says this ;-)  [but it turns out only an
issue for xen]

I now find that:

   on GENERIC on real hardware, "ifconfig wg0 create" loads the module
   
   on XEN3_DOMU, "ifconfig wg0 create" prints
     ifconfig: clone_command: Invalid argument
     ifconfig: exec_matches: Invalid argument

so there's some kind of bug under xen.  However, with "pseudo-device wg"
in the kernel config, it works fine.

I wonder if this is a more general module bug, or a if_wg bug.   nothing
in dmesg.

> The remaining issues are mainly:

Thanks for the list.

> I've been using wg(4) daily for years, and the main issue I hit is
> that it gets stuck once every few weeks or months requiring taking the
> interface down and back up again, usually when changing networks.
> Haven't gotten around to digging further into it.

Is this on the rover only, or does the server have problems?

> I use port 51820 and I have sometimes been surprised that it is let
> through on some otherwise restricted networks (e.g., blocking ssh) but
> this anecdote, not data.

I am increasingly finding wifi networks (that purportedly intend to
offer service to visitors to a business) that are blocking everything
but 80/443.  They even seem to have some kind of blocklist for Tor, and
I haven't even gotten obfs4 to work.  I realize wg is unlikely to work
in such a situation.



Home | Main Index | Thread Index | Old Index