Consul Connect and WireGuard?

862 views
Skip to first unread message

Rolf Sommerhalder

unread,
Jul 7, 2018, 7:21:58 AM7/7/18
to wire...@lists.zx2c4.com, consu...@googlegroups.com
(Cross-posting on Consul's Google group and WireGuard's mailing list.)

Hello,

After watching the keynotes [1], are you also asking yourself if
Consul's Service Mesh is a cloud-native Control Plane for dynamic
overlay (mesh) networks, and if mTLS with certificates could not be
replaced by WireGuard [2] with private/public keys in the Data Plane?

Could such a combination become be a light-weight (elastic)
alternative to network-centric (static) overlays, such as VxLAN or
EVPN?
Or, Consul could be a much more comprehensive Control Plane for
WireGuard, compared to WireGuard-p2p [3] that uses ad-hoc Distributed
Hash Tables (DHT) for "Service Registration & Discovery"?

Eventually, the user-space Go implementation of WireGuard could be
included into Consul, as HashiCorp already did for its PKI (parts
taken from Vault). This would make the alternate Data Plane portable
to platforms other than Linux, much in line with the idea of running
Consul agents on each node providing a "dial-tone".

However, running Consul on each node might be a chatty and large
Control Plane that may be harder to lock down, compared to WireGuard
network overlays and proxies in the Data Plane. For the Data Plane,
Consul Connect provides nice security controls, such as key
management, or Service Graphs with ACLs and Intentions. As everything
is identity-based and independent of IP addresses, this would fit Zero
Trust Network designs.

Is this idea viable at all and worth further exploration, or do I miss
something?

Thanks,
Rolf

[1] https://www.hashicorp.com/resources/hashidays-2018-full-keynote-armon-mitchell
[2] https://www.wireguard.com
[3] https://github.com/manuels/wireguard-p2p

pba...@hashicorp.com

unread,
Jul 19, 2018, 6:15:30 AM7/19/18
to Consul
Hey Rolf

Yeah I'm personally very interested in wireguard and in general Connect design explored lots of options in this space from IPSec tunnels through writing our own tap device interface, using QUIC etc. I know of at least one person who built a wireguard control plane on top of Consul as a prototype (don't think it was ever mature enough to open source) before the Connect announcement.

None of that is totally off the cards for the long-term future and I think personally that it would not take much work to integrate wireguard with our control plane for a really great PoC SDN solution, the devil though would be in the UX and interop details.

For now mTLS is the way most users and customers are thinking about service security - it's the most versatile and the least opinionated, you don't have to be using containers or running at the hypervisor level to use Connect with mTLS. It is also supported already by mature data-plane components (i.e. proxies) that add a lot of value for L7 service protocols.

As mentioned in my talk, we also consciously wanted to remain platform neutral at the core so coupling tightly to linux containers and networking stack as our initial major transport was not the approach we wanted to take. Wireguard specifically might support all our target OSes eventually but once you are down in the kernel networking level platform-specific inevitable creep in.

You pick up on a lot of questions that would need to be answered before we support other transports too. Another would be how do we cope with the UX of wireguard endpoints connecting to mTLS endpoints? We'd potentially end up with one control plane managing multiple non-interoperable data planes.

If you are interested in playing and thinking about this stuff I'd love to hear what you come up with, but to set expectations, we have plenty to do just to get mTLS control plane where we want it to be which would take precedence in general.

Paul

Rolf Sommerhalder

unread,
Jan 20, 2019, 8:02:59 AM1/20/19
to wire...@lists.zx2c4.com, consu...@googlegroups.com
geniousphp/autowire: Automatically configure Wireguard interfaces in
distributed system. It supports Consul as backend.
https://github.com/geniousphp/autowire

- This project is at an early stage development and is not production
ready even though we're running it in our production.
- zero configuration: automatically configure WireGuard. If you're
running a Consul cluster and willing to configure WireGuard as VPN
solution
- Autowire leverages distributed locking of Consul to ensure that
picked IP address is not used by any other WireGuard peer. This method
is described in the leader election guide.
- Autowire to automatically reconfigure WireGuard Peers when nodes
join or leave the Consul cluster
- Autowire uses Consul KV to store WireGuard interface and Peers configurations.


from
https://twitter.com/RealGophersShip/status/1085924076101734400

Built with Go‏ @RealGophersShip
geniousphp/autowire (0.1.2): Automatically configure Wireguard
interfaces in distributed system. It supports Consul as backend


---

Gawen/WireHub: Simple, small, peer-to-peer, decentralized, extensible VPN
https://github.com/Gawen/WireHub

WireHub (in a shell, wh) is a simple, small, peer-to-peer,
decentralized, extensible VPN. It uses WireGuard tunnels and provides
distributed peer discovery & routing capabilities, NAT trasversal,
extendable name resolving, ...

It is written in C and Lua and is <10KLOC.

⚠️ Not ready for production! This is still a work-in-progress. It
still requires some work to be clean and secure. The current code is
provided for testing only.

Features

Simple network description: the minimal configuration of a network is
a list of the public key, private IP and hostname for each member.

Cryptographic network addresses: the network address of a peer is - or
derived from - a Curve25519 public key.

Decentralized discovery: WireHub peers form a Kademilia DHT network
which is the by-default discovery mechanism to find new peers. Sybil
attack is mitigated with a configurable Proof-of-Work parameter;

Peer-to-Peer and relayed communication: WireHub goes through NATs,
using UPnP IGD to map new ports on compatible routers, or using UDP
Hole Punching techniques. If a P2P communication cannot be
established, network traffic is relayed through trusted relayed
servers or peers from the community of WireHub nodes.


from
Frank Denis‏ @jedisct1 23 Dec 2018
https://twitter.com/jedisct1/status/1076616635748925440

WireHub is a simple, small, peer-to-peer, decentralized, extensible
VPN. It uses WireGuard tunnels and provides distributed peer discovery
& routing capabilities, NAT traversal, flexible name resolution, and
more.

Rolf Sommerhalder

unread,
Jan 31, 2019, 5:20:37 AM1/31/19
to wire...@lists.zx2c4.com, consu...@googlegroups.com
> Gawen/WireHub: Simple, small, peer-to-peer, decentralized, extensible VPN
> https://github.com/Gawen/WireHub


wirehub - decentralized, peer-to-peer and secure overlay networks
built with WireGuard
Gawen ARAB g at wenarab.com
Tue Jan 29 22:12:33 CET 2019
https://lists.zx2c4.com/pipermail/wireguard/2019-January/003835.html
Reply all
Reply to author
Forward
0 new messages