Date: Tue, 23 Aug 2022 20:52:06 +0200 From: Milan Obuch <freebsd-net@dino.sk> To: freebsd-net@freebsd.org Cc: tt78347@protonmail.com, grembo@freebsd.org Subject: Re: Tunnel interfaces and vnet boundary crossing Message-ID: <20220823205206.79cc7155@zeta.dino.sk> In-Reply-To: <DSv5_R2RSPi3WtHuwrcckIA4cW-3SSU5nH3a_qyLoa6jItMHdYriEiOGG1q-LRyzDPz2VCqC8ZoTUEZwo1WK2QBWXQivGR3pXdORz0JFeOs=@protonmail.com> References: <3N4WPlYG_OY2JAm4Rg5nWFjqo650j0ccOEOUWSwvWEp9cOudWPfFQ3C54QddWJcqyKd450QB7eczvghXmHbgImkn0tk2pAg7zbn49dJlPtM=@protonmail.com> <20220823175918.4696603f@zeta.dino.sk> <DSv5_R2RSPi3WtHuwrcckIA4cW-3SSU5nH3a_qyLoa6jItMHdYriEiOGG1q-LRyzDPz2VCqC8ZoTUEZwo1WK2QBWXQivGR3pXdORz0JFeOs=@protonmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 Aug 2022 18:06:59 +0000
tt78347 <tt78347@protonmail.com> wrote:
> ------- Original Message -------
> On Tuesday, August 23rd, 2022 at 3:58 PM, Milan Obuch
> <freebsd-net@dino.sk> wrote:
[ snip ]
> > > There is an additional vnet jail which handles ipsec; the ipsec
> > > jail connects the host's jail network (usually a /24) to other
> > > local networks. Each external local network's route is specified
> > > in the host's routing table, with a next-hop being the ipsec
> > > jail. I personally don't use ipsec interfaces, so in the ipsec
> > > jail the traffic is extracted by the kernel (per TSs that are
> > > configured with StrongSwan), encapsulated and sent out the host's
> > > external interface. I have no knowledge of whether this is better
> > > or worse than using an ipsec interface.
> >
> > This one is interested for me. Could you elaborate more on its
> > design? Output of 'ifconfig', 'netstat -rn', 'pkg info', 'cat
> > /etc/rc.conf' commands would be really usefull. If you do concern
> > about privacy, maybe edit it a bit (I am not interested in exact
> > IPs and such info).
>
> I think I had misunderstood your original post, but here is
> information about this ipsec jail. I have replaced certain info with
> variable names.
>
> # cat /etc/rc.conf
>
> devfs_load_rulesets="YES"
>
> hostname="$HOSTNAME"
> syslogd_enable="YES"
> syslogd_flags="-s -v -v"
>
> inetd_enable="NO"
>
> defaultrouter="${HOST_NET}.1"
>
> firewall_enable="YES"
> firewall_script="/etc/ipfw.conf"
> firewall_logif="YES"
>
> sendmail_enable="NO"
> sendmail_submit_enable="NO"
> sendmail_outbound_enable="NO"
> sendmail_msp_queue_enable="NO"
>
> # cat /etc/ipfw.conf
> ipfw add allow ip from any to any
> # cat /etc/rc.conf.local
> strongswan_enable="YES"
> # netstat -rn
> Routing tables
>
> Internet:
> Destination Gateway Flags Netif Expire
> default ${HOST_NET}.1 UGS epair${JAIL_ID}b
> 127.0.0.1 link#1 UH lo0
> ${HOST_NET}.0/24 link#${JAIL_ID} U
> epair${JAIL_ID}b ${HOST_NET}.${JAIL_ID} link#${JAIL_ID}
> UHS lo0
>
>
> This ipsec jail has epair IP address of ${HOST_NET}.${JAIL_ID}.
> For example, 192.168.1.100, where $JAIL_ID=100 and $HOST_NET=192.168.1
> The host's bridge is at ${HOST_NET}.1
> The only relevant package in this jail is security/strongswan.
>
> In this design, all vnet jails have addresses on $HOST_NET using
> epair interfaces connected to one or more virtual host bridge
> interfaces. ARP takes place on this bridge, and the host forwards
> packets between jails. The ipsec jail is just one of those jails. The
> host also has routes for other sites' local networks. These routes
> are set to go through the ipsec jail. The ipsec jail then
> encapsulates them, and from the host's perspective, when it leaves
> the ipsec jail, it is just ESP/UDP.
>
> In this design, ipsec is used for site-to-site tunneling, and GRE is
> used for use-case-specific tunneling between hosts on this WAN. A
> common use case for this is when a machine needs to set a route or a
> default route through a gateway that is not on a connected subnet.
> Operating ipsec and GRE independently means you can use GRE where
> necessary, with the whole WAN being encapsulated with ipsec. Traffic
> within a host being unencrypted.
Thanks for info. While it does not address directly what I'd like to
do, it is informative and produces something to think of and test.
[ snip ]
> I think I misunderstood your posts. I thought you were running
> openvpn clients, but I see from reading again that you are running
> openvpn servers. I have never run an openvpn server before.
Ah, another source of possible misunderstanding... I'd like to write
description short and concise, but sometimes something important is
missing. Yes, I am running OpenVPN in server mode.
> > > Regarding gre interfaces, I also create these within the jail. I
> > > have not ever had any problems with this. I don't know that a
> > > specific device is needed, so I don't know if devfs is involved
> > > here.
> >
> > This setup just requires connection to outer network, which I would
> > like specifically to be avoided as it makes setup a bit more
> > complicated. Just a reminder, I have almost twenty of running
> > OpenVPN instances in one jail, with almost twenty vnet jails
> > handling the routing for each VPN.
>
> I don't fully understand what is happening. What do you mean by outer
> network, and why would it be an issue to create the GRE tunnel inside
> the jail, instead of creating it outside the jail and moving it into
> the jail?
Well, tunnel (gre, gif, other type) packets have outer and inner
headers with addresses. Outer address is that of tunnel endpoint,
inner one is that of payload. Using an example for creating gre tunnel
ifconfig gre0 create tunnel 192.168.1.10 192.168.2.10 10.0.0.1/30 10.0.0.2
outer addresses are 192.168.1.10 and 192.168.2.10, inner addresses are
10.0.0.1 and 10.0.0.2, possible source for these names is for basic
routing purposes only one address is visible, outer, the other is
hidden inside.
And now the second question... My routing table in vnet jail looks like
this:
Internet:
Destination Gateway Flags Netif Expire
127.0.0.1 link#1 UH lo0
192.168.0.0/16 192.168.101.5 UGS eth1.100
192.168.100.0/24 tun2010 US tun100
192.168.100.1 link#2 UHS lo0
192.168.100.2 link#2 UH tun100
192.168.101.4/30 link#3 U eth1.100
192.168.101.6 link#3 UHS lo0
Here, 192.168.100.0/24 is being used for OpenVPN segment, address taken
from here are assigned to OpenVPN clients when they login. This is for
interface tun100. On eth1.100, there is a link to some remote LAN,
where are some machines to be accessed via OpenVPN. And I strongly
prefer to not add any more routing entries here. How the packet gets
delivered to that remote LAN is not relevant here and should be kept
invisible.
[ snip ]
Regards,
Milan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220823205206.79cc7155>