Hey Julian, That is what I had in mind. Though I was hoping I could put the encryption in NetGraph too so that I would not see that interface on my host where I do not need to see it.
On Tue, 9 Jun 2020 at 05:28, Julian Elischer <jul...@freebsd.org> wrote: > On 5/27/20 4:20 AM, Eugene Grosbein wrote: > > 27.05.2020 15:06, Tom Marcoen wrote: > > > >> Hey all, > >> > >> I'm new to this mailing list and also quite new to FreeBSD (huray, > welcome > >> to me!) so bare with me, please. > >> > >> I'm reading up on Netgraph on how I can integrate it with FreeBSD jails > and > >> I was looking at some of the examples provided in > >> /usr/share/examples/netgraph and now have the following question. > >> The udp.tunnel example shows an iface point-to-point connection but it > is > >> unencrypted. Of course I could encrypt it with an IPsec tunnel on the > host > >> or tunnel it through SSH, but I was wondering whether there exists a > nice > >> Netgraph solution, e.g. a node with two hooks, receiving unencrypted > >> traffic on the inside hook and sending out encrypted traffic on the > outside > >> hook. > > There is ng_mppc(4) netgraph node capable to perform relatively weak > MPPE encryption > > (and/or compression) but it is designed to work with ng_ppp(4) node > encapsulating IP packets into PPP frames. > > I doubt it's very efficient for inter-jail traffic. > > > > Why do you need encryption for inter-jails traffic in first place? > > Encryption is needed for traffic passing untrusted channels where data > interception is possible > > but inter-jail traffic does not leave the kernel at all until it hits > destination jail. > Once you have a udp tunnel set up you just need to set up an IPSEC SA > to to encrypt just that tunnel. > It's not required to do the encryption in netgraph. > there is a script to make the tunnel in > /usr/share/examples.netgraph/udp.tunnel > you just need to set up the SA to catch it.. > you can also if you desire you can also put a netgraph bridge at both > ends of the tunnel and have a single subnet connected by the link. The > bridge nodes are "learning" so they will learn when to send packets over > the link and when not to. > You can also play tricks with FIBs so that tunnel envelope packets and all > other packets use different routing tables. > > > > > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
