Date: Wed, 17 Aug 2022 22:22:45 +0200 From: Michael Gmelin <grembo@freebsd.org> To: Milan Obuch <freebsd-net@dino.sk> Cc: freebsd-net@freebsd.org Subject: Re: Tunnel interfaces and vnet boundary crossing Message-ID: <B53B3729-DFD6-4505-98CC-FBACEFA9623A@freebsd.org> In-Reply-To: <20220815085303.2c5cdb02@zeta.dino.sk> References: <20220815085303.2c5cdb02@zeta.dino.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 15. Aug 2022, at 08:52, Milan Obuch <freebsd-net@dino.sk> wrote: >=20 > =EF=BB=BFHi, >=20 > some time ago I managed to design and implement multi-tenant OpenVPN > server using vnet jails. This way I am able to use more OpenVPN > instances on single public IP. >=20 > This is made possible using tun/tap interface property allowing to > cross vnet boundary - here is part of my initialisation command sequence > for one instance: >=20 > jail -c name=3Dov1 vnet persist > jexec ov1 hostname -s ov1 > jexec ov1 ifconfig lo0 127.0.0.1/8 > jexec ov1 sysctl net.inet.ip.forwarding=3D1 > ifconfig tun1 create vnet ov1 > /usr/local/sbin/openvpn --cd /usr/local/etc/openvpn --daemon ov1 --config o= v1.cfg --writepid /var/run/ov1.pid >=20 > In ov1.cfg, relevant bits are >=20 > port 1001 > management localhost 2001 > dev tun1 >=20 > (Actual numbers are different, but important thing is how they relate > together.) >=20 > This way, OpenVPN process runs in base vnet, using one side of > pre-created tun/tap interface, while networking uses the other side of > this interface in child vnet, isolated from base vnet (and other OpenVPN > instances as well). >=20 > Presently, I am using vlan interfaces on one ethernet interface to > connect individual instances to their respective local network. I'd > like to replace this with some tunnel interface (gif, gre, ideally > ipsec secured). The best way to illustrate is using Cisco config > snippet: >=20 > interface Tunnel1 > vrf forwarding vrf1 > ip address 192.168.0.1 255.255.255.252 > tunnel source Loopback0 > tunnel destination 172.16.0.1 >=20 > This means outer layer uses base route table for tunnel creation, while > inner layer, packets/datagrams transferred over tunnel, use other vrf. >=20 > I tried to mimic this in FreeBSD with following commands: >=20 > ifconfig gre1 create tunnel 172.16.1.1 172.16.0.1 vnet ov1 > jexec ov1 ifconfig gre1 10.1.0.2/30 10.1.0.1 >=20 > This does not work. I found some older post which made me believing > this is caused by clearing whole tunnel configuration after moving > interface into different vnet. My (failed) tests indicate this is most > probably the cause. >=20 > So, my question is, does anybody use tunnel interface similar way? Is > it possible to achieve what I am trying with netgraph? I am able to > create some inter-vnet link using epair interface, but this is > something different. Or ideally, is somebody using IPSEC with VNET > jails, processing encapsulating packets in base and raw content in some > child vnet? >=20 Not sure if that helps you at all, but what I=E2=80=99ve done in the past is= create a tunnel interface on the jailhost and add a devfs rule to allow acc= ess to it from within the vnet jail. I then run OpenVPN within that jail (so= OpenVPN and tunnel interface are in the same jail). It=E2=80=99s super stable, only issue is that you need to be careful when to= release/destroy the interface on jail restart, otherwise it will become una= vailable on the jailhost and in a (new) jail. Best Michael
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B53B3729-DFD6-4505-98CC-FBACEFA9623A>