wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Raffaele Spazzoli <rspazzol@redhat.com>
To: wireguard@lists.zx2c4.com
Subject: what to do when the peers use different IPs to transmit and receive
Date: Sun, 16 Sep 2018 08:21:02 -0400	[thread overview]
Message-ID: <CACOeLq+PG-SFUhSZUejCVWc+uMnBq1ATRwUFFLQZBTCU6JMSew@mail.gmail.com> (raw)

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

Hi,

I am trying to build an encrypted tunnel between two Kubernetes clusters.
The distribution of Kubernetes that I use is OpenShift, so I'll make my
examples in OpenShift although the problem that I'm seeing is really more
general.

The nodes that comprise the cluster in OpenShift have an IP in what we'll
call the enterprise network. Also they establish between each other an SDN.
The SDN will have a separate CIDR from the enterprise network and the pods
that OpenShift starts receive an SDN IP. Each node manages a subnet of the
SDN CIDR.

What I'd like to do is to make the IPs of two different OpenShift SDNs
routable over and encrypted tunnel.

In my design each node of cluster A sees as its VPN peers the nodes of
cluster B. So this creates a sort of a meshed VPN.

Wireguard fits very well this series of requirements, but I have an issue.

Normally the nodes of a cluster are not directly exposed to the internet.
This is for security reasons. Whether the cluster is in the cloud or on
premise, normally what customers do is to use private internal addresses.
To access the cluster one can use VIPs. Especially in the cloud Kubernetes
makes it easy to create VIPs in an automated fashion. VIP are public IPs
that can be used to loadbalanced backed services. UDP VIPS are supported.

So if we assume that the two clusters that we want to connect using
wireguard are in two different geographies and can only be talk over the
internet and through VIPs, then the IP that a  node uses for its outbound
connection is not the same that its peer need to use for its inbound
connections.

Each node can have a dedicated VIP that peers need to use for its inbound
connection and then it will use the node's private IP for its outbound
connection.

In this situation wiregaurd assumes that the peer has changed IP (built-in
roaming feature) and it updates the peer endpoint value. This doesn't work
for my setup.

What can I do to fix this issue?
Or alternatively would it be reasonable to add a flag to make a peer
configuration immutable?



Thanks,
Raffaele

Raffaele Spazzoli
Senior Architect - OpenShift <https://www.openshift.com>, Containers
and PaaS Practice <https://www.redhat.com/en/services/consulting/paas>
Tel: +1 216-258-7717

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

             reply	other threads:[~2018-09-16 12:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-16 12:21 Raffaele Spazzoli [this message]
2018-09-16 16:54 ` what to do when the peers use different IPs to transmit and receive Ivan Labáth
2018-09-16 18:56   ` Raffaele Spazzoli
2018-09-16 23:08     ` Raffaele Spazzoli
2018-09-17  9:16       ` Ivan Labáth
2018-09-17 11:10         ` Raffaele Spazzoli
2018-09-25 21:16           ` Ivan Labáth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACOeLq+PG-SFUhSZUejCVWc+uMnBq1ATRwUFFLQZBTCU6JMSew@mail.gmail.com \
    --to=rspazzol@redhat.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).