
Building a WireGuard jail with FreeBSD's standard tools - rodrigo975
https://genneko.github.io/playing-with-bsd/networking/freebsd-wireguard-jail/
======
rsync
A few different articles this week about spinning up a wireguard
container/jail/VM ...

But it's far, far easier to just fire up an sshd somewhere and 'sshuttle'
makes it possible to turn _any ssh server that you have a login on_ into a VPN
endpoint:

[https://sshuttle.readthedocs.io/en/stable/](https://sshuttle.readthedocs.io/en/stable/)

You don't even need to be a privileged user - just any old user login, over
ssh, and you need python to exist on the remote system.

~~~
tw04
I can't believe the performance of sshuttle is anywhere near Wireguard...?

~~~
yjftsjthsd-h
It wasn't when I used it. It's been too long to remember numbers, but I got a
significant speed improvement by switching from sshuttle to wireguard.

------
stiray
As people are again asking about vm/jails/docker/...

[https://blog.jessfraz.com/post/containers-zones-jails-
vms/](https://blog.jessfraz.com/post/containers-zones-jails-vms/)

It is great article.

Bottom line, jails are "in kernel" primitives. Containers are not (or at least
they werent when I last checked).

~~~
TsiCClawOfLight
Containers are basically a very thin layer on top of namespaces and cgroups,
which are most definitely in kernel primitives.

Docker adds packaging and distribution, but the hard work is in kernel.

~~~
cpuguy83
It's all hard work. The primitives of containerization are in the kernel, but
executing and managing them, especially securely, takes a fair amount of trial
and error to do it right.

------
ggm
Not seeking a v4/v6 flame war, It would be interesting to see the IPv6 version
of this for people who want to use WireGuard to protect IPv6 flows back to
"inside" and so much of this is NAT related, its not generally applicable to
that case.

~~~
loeg
You can NAT IPv6.

~~~
ggm
The NAT exists because it has to.

You could NAT IPv6 to use the model as-is, but you could also re-do the model
to not need NAT but still use wireguard to get through an ACL state which
protects your boundary.

------
jxy
What's the difference between the epair and the tap interfaces?

~~~
sigwinch28
An epair [0] is a pair of virtual ethernet interfaces which are connected
together and have network addresses: ethernet frames that go in one interface
come out of the other.

A tap interface can be used by software to make ethernet traffic appear on an
interface, i.e. software can write to a tap interface to simulate ethernet
traffic being received on that interface, and an application can receive
ethernet traffic from it. From the manpage [1]: "A write(2) call passes an
Ethernet frame in to be "received" on the pseudo-interface. Each write() call
supplies exactly one frame; the frame length is taken from the amount of data
provided to write()."

[0]:
[https://www.freebsd.org/cgi/man.cgi?query=epair&sektion=4&ma...](https://www.freebsd.org/cgi/man.cgi?query=epair&sektion=4&manpath=FreeBSD+12.1-RELEASE)
[1]:
[https://www.freebsd.org/cgi/man.cgi?query=tap&sektion=4&manp...](https://www.freebsd.org/cgi/man.cgi?query=tap&sektion=4&manpath=FreeBSD+12.1-RELEASE)

~~~
ignoramous
Thanks. So, is it possible that wireguard _writes_ to tap and the _bridge_ or
another interface on the host _reads_ from it? Why would one prefer epairs
over tap, if that's the case?

And, I don't really get why _wg-jail_ also needs _default-router_ to be
pointed to _bridge0_ when the author _addm_ s _epair-b_ to _bridge0_ on the
host (which file are the following lines added to anyway?):

\----

cloned_interfaces="bridge0 epair0"

ifconfig_bridge0="inet 192.168.20.1/24 addm epair0b up"

ifconfig_epair0b="up"

\----

And the explicit _default-router_ definition for _wg-jail_ , in _vm
/wg/etc/rc.conf_:

\----

defaultrouter="192.168.20.1"

\----

~~~
jlgaddis
> _I don 't really get why wg-jail also needs default-router to be pointed to
> bridge0 when the author addms epair-b to bridge0 on the host._

The _epair0_ interfaces provide the layer 2 (Ethernet) connection between the
jail and the host. The jail still needs a default IPv4 (layer 3) gateway so
that it can route the traffic coming fron the WireGuard clients back out to
the network/Interet (same as any other "router").

(Note: With just a single jail -- such as in this case -- the _bridge0_
interface isn't actually necessary (and the 192.168.20.1 address would then be
assigned to the _epair0b_ , not _bridge0_ , interface on the host). The author
went ahead and created a bridge with the intention to create additional jails
in the future. This way, multiple jails can all be connected to the same
internal "jail network". This is all mentioned in TFA, by the way.)

> _which file are the following lines added to anyway?_
    
    
      cloned_interfaces="bridge0 epair0"
      ifconfig_bridge0="inet 192.168.20.1/24 addm epair0b up"
      ifconfig_epair0b="up"
    

Those go in /etc/rc.conf on the host.

    
    
      defaultrouter="192.168.20.1"
    

This goes in /etc/rc.conf on the jail (which corresponds to /vm/wg/etc/rc.conf
on the host).

------
rubatuga
Anybody know what the benefits of a BSD jail might be over a VM?

~~~
simcop2387
lighter weight than a VM. It uses the same kernel as the rest of the system,
but sandboxes the userspace to limit what impact it can have on the rest of
the system. They're not quite equivalent to a container on Linux but they're
very similar in functionality.

~~~
Lammy
VNET jails, as the author is using, also have a completely stand-alone network
stack from the host-OS!

------
Mic92
I wonder if FreeBSD can saturate 1Gbit/s with the TUN wireguard driver.
Linux's native driver is likely faster.

~~~
craftkiller
Netgate[1] is sponsoring the development of an in-kernel implementation of
wireguard for FreeBSD:
[https://forum.netgate.com/post/891869](https://forum.netgate.com/post/891869)

[1]: Netgate is the company behind pfsense, a router/firewall distro of
FreeBSD

~~~
mdtancsa
Any idea whats the target date for it in the tree ?

~~~
gonzo
when it's ready, of course.

It just started passing packets (ping) last week. It would have been at this
point weeks ago, had Jason not baked his e-mail address into the handshake
protocol. (Harumph.)

~~~
loeg
Matt changing random algorithm parameters he didn't understand is kind of on
him, sorry. I'm glad of the work he's doing, and your funding of FreeBSD
native wireguard work, but just changing random cryptographic parameters
before had had packets passing was an exercise in foot-shooting.

~~~
joeschmooo
It was certainly naive of him. However, can't deny that baking the authors
e-mail & domain name in to the protocol is pretty narcissistic.

