Babel over wireguard

Babel over wireguard

[Ryan Whelan]

[-- Attachment #1: Type: text/plain, Size: 256 bytes --]

I'm looking to run babel over wireguard links and running into issues.  I
seem to be unable to get Bird or the reference implementation of Babel to
bind to any wireguard interfaces.  Is this a known issue? or has anyone
found a config that works?

thanks!

[-- Attachment #2: Type: text/html, Size: 310 bytes --]

Re: Babel over wireguard

[Toke Høiland-Jørgensen]

On 6 December 2017 13:07:56 CET, Ryan Whelan <rcwhelan@gmail=2Ecom> wrote:
>I'm looking to run babel over wireguard links and running into issues=2E=
=20
>I
>seem to be unable to get Bird or the reference implementation of Babel
>to
>bind to any wireguard interfaces=2E  Is this a known issue? or has anyone
>found a config that works?

You need to manually add link-local IPs (fe80:: something) to the wireguar=
d interface=2E Also, since wireguard doesn't support multicast it is only l=
ikely to work on point-to-point links with AllowedIPs set to ::/0 (or somet=
hing else that includes the Babel multicast address)=2E

-Toke

Re: Babel over wireguard

[Ryan Whelan]

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Are there any routing protocol implementations that do not depend on
multicast?  In my setup, 2 hosts will be able to route to one another over
2 different wg interfaces and I just need something to select whichever
interface has the least latency.  Anything like that exist? :D

On Wed, Dec 6, 2017 at 7:33 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

>
>
> On 6 December 2017 13:07:56 CET, Ryan Whelan <rcwhelan@gmail.com> wrote:
> >I'm looking to run babel over wireguard links and running into issues.
> >I
> >seem to be unable to get Bird or the reference implementation of Babel
> >to
> >bind to any wireguard interfaces.  Is this a known issue? or has anyone
> >found a config that works?
>
> You need to manually add link-local IPs (fe80:: something) to the
> wireguard interface. Also, since wireguard doesn't support multicast it is
> only likely to work on point-to-point links with AllowedIPs set to ::/0 (or
> something else that includes the Babel multicast address).
>
> -Toke
>

[-- Attachment #2: Type: text/html, Size: 1477 bytes --]

Re: Babel over wireguard

[Toke Høiland-Jørgensen]

Ryan Whelan <rcwhelan@gmail.com> writes:

> Are there any routing protocol implementations that do not depend on
> multicast?

We are in the process of standardising Babel, and one of the things we
are adding is the ability to run entirely over unicast. So in the
future, Babel will be able to do this (and integration with Wireguard is
one of the things I want to achieve with this). But for now, no
implementation exists.

Other than that, maybe BGP? But you'd still need integration with
Wireguard if you don't want to just set AllowedIPs to ::/0

> In my setup, 2 hosts will be able to route to one another over 2
> different wg interfaces and I just need something to select whichever
> interface has the least latency. Anything like that exist? :D

You can do this with point-to-point wireguard links. I.e., as long as
the wireguard link only has two peers, you can set AllowedIPs to
0.0.0.0/0, ::/0 on both sides, assign manual link-local addresses
(anything in fe80::/64 will work, so you could just assign fe80::1/64 to
one side and fe80::2/64 to the other side; they don't need to be
globally unique either). Then you can run babeld on top, which will
instruct the kernel to send appropriate packets to the wireguard
interface, and wireguard will forward it to the other side.

It's not currently possible to run a routing daemon on a multi-peer
wireguard interface. The routing daemon would need to reconfigure
wireguard in the kernel when it adds routes. I am planning to add this
to Bird at some point, but have not gotten around to it yet...

-Toke

Re: Babel over wireguard

[Ryan Whelan]

[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]

If you're gauging interest, I would be very interested in using unicast
atop Wireguard for routing selection

Thank you for the explanation; very helpful.


On Wed, Dec 6, 2017 at 8:11 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Ryan Whelan <rcwhelan@gmail.com> writes:
>
> > Are there any routing protocol implementations that do not depend on
> > multicast?
>
> We are in the process of standardising Babel, and one of the things we
> are adding is the ability to run entirely over unicast. So in the
> future, Babel will be able to do this (and integration with Wireguard is
> one of the things I want to achieve with this). But for now, no
> implementation exists.
>
> Other than that, maybe BGP? But you'd still need integration with
> Wireguard if you don't want to just set AllowedIPs to ::/0
>
> > In my setup, 2 hosts will be able to route to one another over 2
> > different wg interfaces and I just need something to select whichever
> > interface has the least latency. Anything like that exist? :D
>
> You can do this with point-to-point wireguard links. I.e., as long as
> the wireguard link only has two peers, you can set AllowedIPs to
> 0.0.0.0/0, ::/0 on both sides, assign manual link-local addresses
> (anything in fe80::/64 will work, so you could just assign fe80::1/64 to
> one side and fe80::2/64 to the other side; they don't need to be
> globally unique either). Then you can run babeld on top, which will
> instruct the kernel to send appropriate packets to the wireguard
> interface, and wireguard will forward it to the other side.
>
> It's not currently possible to run a routing daemon on a multi-peer
> wireguard interface. The routing daemon would need to reconfigure
> wireguard in the kernel when it adds routes. I am planning to add this
> to Bird at some point, but have not gotten around to it yet...
>
> -Toke
>

[-- Attachment #2: Type: text/html, Size: 2544 bytes --]

Re: Babel over wireguard

[Toke Høiland-Jørgensen]

Ryan Whelan <rcwhelan@gmail.com> writes:

> If you're gauging interest, I would be very interested in using
> unicast atop Wireguard for routing selection

Noted. No promises as to when I'll get around to implementing this,
though ;)

> Thank you for the explanation; very helpful.

You're very welcome!

-Toke

Re: Babel over wireguard

[Lucian Cristian]

[-- Attachment #1: Type: text/plain, Size: 2725 bytes --]

On 06.12.2017 15:22, Ryan Whelan wrote:
> If you're gauging interest, I would be very interested in using 
> unicast atop Wireguard for routing selection
>
> Thank you for the explanation; very helpful.
>
>
> On Wed, Dec 6, 2017 at 8:11 AM, Toke Høiland-Jørgensen <toke@toke.dk 
> <mailto:toke@toke.dk>> wrote:
>
>     Ryan Whelan <rcwhelan@gmail.com <mailto:rcwhelan@gmail.com>> writes:
>
>     > Are there any routing protocol implementations that do not depend on
>     > multicast?
>
>     We are in the process of standardising Babel, and one of the things we
>     are adding is the ability to run entirely over unicast. So in the
>     future, Babel will be able to do this (and integration with
>     Wireguard is
>     one of the things I want to achieve with this). But for now, no
>     implementation exists.
>
>     Other than that, maybe BGP? But you'd still need integration with
>     Wireguard if you don't want to just set AllowedIPs to ::/0
>
>     > In my setup, 2 hosts will be able to route to one another over 2
>     > different wg interfaces and I just need something to select
>     whichever
>     > interface has the least latency. Anything like that exist? :D
>
>     You can do this with point-to-point wireguard links. I.e., as long as
>     the wireguard link only has two peers, you can set AllowedIPs to
>     0.0.0.0/0 <http://0.0.0.0/0>, ::/0 on both sides, assign manual
>     link-local addresses
>     (anything in fe80::/64 will work, so you could just assign
>     fe80::1/64 to
>     one side and fe80::2/64 to the other side; they don't need to be
>     globally unique either). Then you can run babeld on top, which will
>     instruct the kernel to send appropriate packets to the wireguard
>     interface, and wireguard will forward it to the other side.
>
>     It's not currently possible to run a routing daemon on a multi-peer
>     wireguard interface. The routing daemon would need to reconfigure
>     wireguard in the kernel when it adds routes. I am planning to add this
>     to Bird at some point, but have not gotten around to it yet...
>
>     -Toke
>
>
>
>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

I'm usig frr routing with eigrp over wg

EIGRP: eigrpd 3.1-dev starting: vty@2613
EIGRP: interface 192.168.123.1 [10] join EIGRP Multicast group.
EIGRP: interface 172.16.223.2 [15] join EIGRP Multicast group.
EIGRP: Neighbor 172.16.223.1 (wg0) is pending: new adjacency
EIGRP: Neighbor(172.16.223.1) adjacency became full

but it can be used as unicast specifing the neighbor, but with no 
interface for the moment, is under development

Regards



[-- Attachment #2: Type: text/html, Size: 4839 bytes --]