Kernel doesnt support WireGuard Protocol

51 views
Skip to first unread message

bo0od

unread,
Apr 17, 2019, 8:19:27 AM4/17/19
to qubes...@googlegroups.com
I was trying to install wireguard in debian , i installed it
successfully but it wont run due to kernel issue (according to what i
have tested)

you can test wireguard on fresh debain VS debian in Qubes

https://www.wireguard.com/

unman

unread,
Apr 17, 2019, 9:48:57 AM4/17/19
to qubes...@googlegroups.com
The wireguard packages are only available in sid, so it's no surprise
they are broken in Qubes. Last time I tried sid was pretty broken all
round.
Or are you installing from source?
You will, I think, also need to run a custom kernel in the wireguard qube,
to use dkms. Have you done this? There's guidance -
https://www.qubes-os.org/doc/managing-vm-kernel/

Simon Newton

unread,
Apr 17, 2019, 10:03:30 AM4/17/19
to unman, qubes-devel
>The wireguard packages are only available in sid, so it's no surprise
> they are broken in Qubes

WG is available in stretch, using package pinning and unstable repo. They work fine for me in many stretch installs. See https://wiki.debian.org/Wireguard for the overview

That being said, wireguard-dkms will fail when trying to install, as correctly pointed out a different kernel is required as the pvops kernels have stuff in the identifier that wireguard-dkms builder does not like. A quick route without going through the kernel route unman mentions could be to install from debian ISO using HVM. Though please read up here before doing so and understand the risks to your threat model by using HVM

--
You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20190417134854.xtwipj37uqwi56ij%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.


--
Kind Regards,

Simon Newton

E: Simon....@gmail.com

Outback Dingo

unread,
Apr 17, 2019, 10:20:03 AM4/17/19
to Simon Newton, unman, qubes-devel
On Wed, Apr 17, 2019 at 9:03 PM Simon Newton <simon....@gmail.com> wrote:
>
> >The wireguard packages are only available in sid, so it's no surprise
> > they are broken in Qubes

actually you dont need to compile wg kernel modules if you want it to
be a client, just use TunSafe client for the client to the real remote
wireguard server

unman

unread,
Apr 17, 2019, 11:38:58 AM4/17/19
to qubes-devel
Please don't top-post - it makes it more difficult to follow the thread.

Yes, the packages *can* be installed in stretch, but they are only
available in sid. It's not generally good practice to do this.

The advantage of the route I suggested is that you have the benefit of
HVM mode and custom kernel without needing to install anew, so *that* is
somewhat quicker. Either works fine.
works, of course, but that's somewhat quicker.

Simon Newton

unread,
Apr 17, 2019, 12:12:09 PM4/17/19
to unman, qubes-devel
On Wed, Apr 17, 2019 at 4:38 PM unman <un...@thirdeyesecurity.org> wrote:


Please don't top-post - it makes it more difficult to follow the thread.

Ugh.. gmail. must.....remember...... click.....three......dots....
 
Yes, the packages *can* be installed in stretch, but they are only
available in sid. It's not generally good practice to do this

Both wireguard and debian docs state this as the official way to install wireguard. Debian docs even go as taking the unusual step of stating this will work in stretch and jessie, which I dont think I have seen anywhere else in debian stable docs when using unstable/sid pinning. For your average deb package, this is definitatley not good practice. For wireguard-dkms which is built against the locally installed kernel headers, the risk is very very low.

The advantage of the route I suggested is that you have the benefit of
HVM mode and custom kernel without needing to install anew, so *that* is
somewhat quicker. Either works fine.
works, of course, but that's somewhat quicker.

Perhaps I should have said "less human resource intensive?" ;) 
 
Reply all
Reply to author
Forward
0 new messages