WireGuard Archive on lore.kernel.org
 help / Atom feed
* Host routes – ARP on wireguard interfaces?
@ 2018-12-03 12:02 Matthias Urlichs
  2018-12-03 13:14 ` Toke Høiland-Jørgensen
  0 siblings, 1 reply; 4+ messages in thread
From: Matthias Urlichs @ 2018-12-03 12:02 UTC (permalink / raw)
  To: WireGuard mailing list

Hi,

My problem: I have a couple of host routes within my network that point
to a service's "current master". When that machine goes down, I need to
automatically redirect its address to a different gateway. That's easy –
lookup the nexthop for the "real" server address and change the host
route – except when the destination is on wireguard and needs to be
(re)directed to a (different) peer.

My preferred solution for this (and also the one that is most intuitive
IMHO) would be some sort of pseudo-ARP – just enough to make "ip route
add FOO via BAR" work, 'BAR' being a host address that's associated with
exactly one wireguard peer.

Thoughts?

-- 
-- Matthias Urlichs

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Host routes – ARP on wireguard interfaces?
  2018-12-03 12:02 Host routes – ARP on wireguard interfaces? Matthias Urlichs
@ 2018-12-03 13:14 ` Toke Høiland-Jørgensen
  2018-12-03 13:49   ` Matthias Urlichs
  0 siblings, 1 reply; 4+ messages in thread
From: Toke Høiland-Jørgensen @ 2018-12-03 13:14 UTC (permalink / raw)
  To: Matthias Urlichs, WireGuard mailing list

Matthias Urlichs <matthias@urlichs.de> writes:

> Hi,
>
> My problem: I have a couple of host routes within my network that point
> to a service's "current master". When that machine goes down, I need to
> automatically redirect its address to a different gateway. That's easy –
> lookup the nexthop for the "real" server address and change the host
> route – except when the destination is on wireguard and needs to be
> (re)directed to a (different) peer.
>
> My preferred solution for this (and also the one that is most intuitive
> IMHO) would be some sort of pseudo-ARP – just enough to make "ip route
> add FOO via BAR" work, 'BAR' being a host address that's associated with
> exactly one wireguard peer.
>
> Thoughts?

I'm not sure I quite understand what it is you are trying to achieve;
why can't just you reconfigure the wireguard interface to route the IP
to the right peer?

-Toke
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Host routes – ARP on wireguard interfaces?
  2018-12-03 13:14 ` Toke Høiland-Jørgensen
@ 2018-12-03 13:49   ` Matthias Urlichs
  2018-12-03 19:39     ` Toke Høiland-Jørgensen
  0 siblings, 1 reply; 4+ messages in thread
From: Matthias Urlichs @ 2018-12-03 13:49 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, WireGuard mailing list

[-- Attachment #1.1.1: Type: text/plain, Size: 1307 bytes --]

On 03.12.18 14:14, Toke Høiland-Jørgensen wrote:
> I'm not sure I quite understand what it is you are trying to achieve;
> why can't just you reconfigure the wireguard interface to route the IP
> to the right peer?

Because that (a) requires a new mechanism and (b) requires locking,
because currently you can't atomically remove/add an address from/to a peer.

For a "normal" interface I'd change the host route to whatever the
nexthop to the real destination address is, and I'm *done*. That's one
atomic "ip route replace" command (or its netlink equivalent). I've
found a couple of HA management programs which can do that.

For a wireguard interface I need to find the correct peer (by matching
the real destination against all Allowed-IP entries), lock the peer
against changes, read the Allowed-IP list, add the multihomed address,
and write the list back. Before/after I do all of this I have to remove
the multihomed address from whatever peer it was previously set to, so
there's an indeterminate time during which the destination is either
unreachable or random. The aforementioned HA managers have no idea what
wireguard is, and their authors may or may not be interested in
special-casing a still-somewhat-obscure network interface type.

-- 
-- Matthias Urlichs



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

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Host routes – ARP on wireguard interfaces?
  2018-12-03 13:49   ` Matthias Urlichs
@ 2018-12-03 19:39     ` Toke Høiland-Jørgensen
  0 siblings, 0 replies; 4+ messages in thread
From: Toke Høiland-Jørgensen @ 2018-12-03 19:39 UTC (permalink / raw)
  To: Matthias Urlichs, WireGuard mailing list

Matthias Urlichs <matthias@urlichs.de> writes:

> On 03.12.18 14:14, Toke Høiland-Jørgensen wrote:
>> I'm not sure I quite understand what it is you are trying to achieve;
>> why can't just you reconfigure the wireguard interface to route the IP
>> to the right peer?
>
> Because that (a) requires a new mechanism and (b) requires locking,
> because currently you can't atomically remove/add an address from/to a peer.
>
> For a "normal" interface I'd change the host route to whatever the
> nexthop to the real destination address is, and I'm *done*. That's one
> atomic "ip route replace" command (or its netlink equivalent). I've
> found a couple of HA management programs which can do that.
>
> For a wireguard interface I need to find the correct peer (by matching
> the real destination against all Allowed-IP entries), lock the peer
> against changes, read the Allowed-IP list, add the multihomed address,
> and write the list back. Before/after I do all of this I have to remove
> the multihomed address from whatever peer it was previously set to, so
> there's an indeterminate time during which the destination is either
> unreachable or random. The aforementioned HA managers have no idea what
> wireguard is, and their authors may or may not be interested in
> special-casing a still-somewhat-obscure network interface type.

I'm pretty sure you don't have to go through that whole dance. You can
just add the AllowedIP to the new peer, which Wireguard will interpret
as a 'move'.

That still leaves the 'new mechanism' complaint, of course. I'm not sure
it's quite trivial to have the kernel-side do what you want, though, so
it may not be something that is likely to show up. I have a similar
problem because I want to run routing protocols over wireguard; my plan
is to teach the Bird routing daemon about wg peers to resolve this...

-Toke
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-03 12:02 Host routes – ARP on wireguard interfaces? Matthias Urlichs
2018-12-03 13:14 ` Toke Høiland-Jørgensen
2018-12-03 13:49   ` Matthias Urlichs
2018-12-03 19:39     ` Toke Høiland-Jørgensen

WireGuard Archive on lore.kernel.org

Archives are clonable: git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/ public-inbox