Re: Wireguard and VRFs?

Re: Wireguard and VRFs?

[Florian Werner]

Hi Jason,

does Wireguard support to bind to a specific interface?

For e.g. gre interface it is possible with
ip tunnel add name gre0 mode gre remote 1.2.3.4 dev eth0
to bind the gre0 interface to eth0.

Quoting ip-tunnel(8):
dev NAME
	bind the tunnel to the device NAME so that tunneled
	packets will only be routed via this device and will
	not be able to escape to another device when the route
	to endpoint changes.

But I don't think ip link supports this.
The question is, why are there 2 commands to create new
interfaces (ip link add, ip tunnel add)...

With binding support one can simply bind to a vrf master
interface and all outer-traffic is sent to the associated
routing table. Using vrf instead of network namespace has
the advantage of allowing daemons to operate in multiple
vrf (e.g. routing daemons), where network namespace are
more separated but also don't allow much communication.

Florian

Re: Wireguard and VRFs?

[Jörg Thalheim]

You assign a firewall mark to each wireguard interface to route dedicated routing table using ip rule.
wg-quick use this feature for example, when you redirect 0.0.0.0 via a vpn interface:

$ wg-quick up mullvad
[#] ip link add mullvad type wireguard
[#] wg setconf mullvad /dev/fd/63
[#] ip address add 10.99.1.142/32 dev mullvad
[#] ip address add fc00:bbbb:bbbb:bb01::18e/128 dev mullvad
[#] ip link set mtu 1420 dev mullvad
[#] ip link set mullvad up
[#] wg set mullvad fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev mullvad table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0


On 2017-09-20 04:12, Florian Werner wrote:
> Hi Jason,
>
> does Wireguard support to bind to a specific interface?
>
> For e.g. gre interface it is possible with
> ip tunnel add name gre0 mode gre remote 1.2.3.4 dev eth0
> to bind the gre0 interface to eth0.
>
> Quoting ip-tunnel(8):
> dev NAME
> 	bind the tunnel to the device NAME so that tunneled
> 	packets will only be routed via this device and will
> 	not be able to escape to another device when the route
> 	to endpoint changes.
>
> But I don't think ip link supports this.
> The question is, why are there 2 commands to create new
> interfaces (ip link add, ip tunnel add)...
>
> With binding support one can simply bind to a vrf master
> interface and all outer-traffic is sent to the associated
> routing table. Using vrf instead of network namespace has
> the advantage of allowing daemons to operate in multiple
> vrf (e.g. routing daemons), where network namespace are
> more separated but also don't allow much communication.
>
> Florian
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Wireguard and VRFs?

[Jason A. Donenfeld]

Hi Max,

Yes, WireGuard supports this type of functionality through two more
powerful mechanisms:

- fwmark, so you can do proper policy-based routing via `ip rule` with
multiple tables
- network namespace, so that you can have the udp socket in one
namespace and the actual interface in another

I imagine what you want is the fwmark feature, which seems to match up
with much of the language used in vrf.txt. Check out the wg(8) manpage
for details.

Regards,
Jason

Wireguard and VRFs?

[Maximilian Wilhelm]

Hi folks,

I just stumbled across wireguard and really like it!

While reading the docs and seeing the notes on network name spaces I
started wondering if there's any support for Linux VRFs? [0]

What I'd like to do is builing a VPN tunnel using VRF "external" and
terminate the tunnel within the main VRF. For OpenVPN this required a
patch [65] for the setsockopt() but then works fine. Is something like
this already possible with Wireguard?

And if not would you be open to adding it or merging a patch for it?
I didn't look through the code yet, but I would suggest an option for the
tun interface which will then trigger a setsockopt() call. Like a
parameter for iproute for type wireguard interfaces.

Thanks a lot!
Best
Max

[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/vrf.txt
[65] https://github.com/OpenVPN/openvpn/pull/65
-- 
"I have to admit I've always suspected that MTBWTF would be a more useful
 metric of real-world performance."
 -- Valdis Kletnieks on NANOG