wg trunk (TM) traffic isolation: VRF vs netns

wg trunk (TM) traffic isolation: VRF vs netns

[jrun]

hello,

my use case is, if possible, is to provide vpn to friends and family and also
peering with other wg nodes (work etc). this obviously needs traffic isolation
and i have though about it for a while but don't have definitive answer.

1. on way i thought of doing is to have a point-to-point (dedicated wg interface
for each user) solution.

2. the other is to group interfaces based on the category of users (think friends
vs family vs even work).

they both probably need writing up something for set-up and tear-down each of
interfaces which should be fine but both would need a way of isolating traffic;
either between indivitual user's interface or between group interfaces. there is
also the question of ACL'ing the site-to-site traffic for each group and/or
user.

for this i've looked into VRF and netns; this has been brought up before
here and other place but i don't seem to be able to read the conclusion:
https://lists.zx2c4.com/pipermail/wireguard/2017-September/001706.html

from outside it looks like cumulus devs like their VRF, and wireguard devs lean
recommend using netns

https://www.wireguard.com/netns/

that^ link is not a solution for me but i can think of ways to use netns for
my case.


thoughts?

- jrun

Re: wg trunk (TM) traffic isolation: VRF vs netns

[Tomcsanyi, Domonkos]

Hi,

Using different network ranges for different groups of people + applying correct iptables rules shall be a simple solution, utilizing a single WG interface. People will get a static IP assigned in their respective range, so they are not allowed to use anything else as source address, so cannot circumvent iptables.

Cheers,
Domi

> 22.12.2020 dátummal, 16:36 időpontban jrun <darwinskernel@gmail.com> írta:
> 
> 
> hello,
> 
> my use case is, if possible, is to provide vpn to friends and family and also
> peering with other wg nodes (work etc). this obviously needs traffic isolation
> and i have though about it for a while but don't have definitive answer.
> 
> 1. on way i thought of doing is to have a point-to-point (dedicated wg interface
> for each user) solution.
> 
> 2. the other is to group interfaces based on the category of users (think friends
> vs family vs even work).
> 
> they both probably need writing up something for set-up and tear-down each of
> interfaces which should be fine but both would need a way of isolating traffic;
> either between indivitual user's interface or between group interfaces. there is
> also the question of ACL'ing the site-to-site traffic for each group and/or
> user.
> 
> for this i've looked into VRF and netns; this has been brought up before
> here and other place but i don't seem to be able to read the conclusion:
> https://lists.zx2c4.com/pipermail/wireguard/2017-September/001706.html
> 
> from outside it looks like cumulus devs like their VRF, and wireguard devs lean
> recommend using netns
> 
> https://www.wireguard.com/netns/
> 
> that^ link is not a solution for me but i can think of ways to use netns for
> my case.
> 
> 
> thoughts?
> 
> - jrun

Re: wg trunk (TM) traffic isolation: VRF vs netns

[Matthias Urlichs]

[-- Attachment #1.1: Type: text/plain, Size: 860 bytes --]

Hello,
> thoughts?
>
> - jrun

When in doubt, do both.

I am running my home router as a couple of netns domains on one of the 
less-overworked servers in the basement, facilitated by a couple of 
"dumb" scripts that set it all up.

My setup: create a netns instance, move the machine's main interface 
into it, setup VLANs and bridges in there, and then add a veth interface 
to one of the bridges whose other end is moved back to the root namespace.

Bonus points, the router instance doesn't have any services (thus only 
needs FORWARD firewall rules) and can run on basically any local system 
with enough bandwidth. Just add VLANs to its interface on the switch.

Within that router netns I have separate VRFs for "sensitive" and 
"guest" traffic, mainly to simplify firewall rules and routing tables.

-- 
-- Matthias Urlichs



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]