WireGuard: Cryptokey Routing

Key Point 1: At the heart of WireGuard is a concept called Cryptokey Routing, which works by associating public keys with a list of tunnel IP addresses that are allowed inside the tunnel.

Key Point 2: Each network interface has a private key and a list of peers.

Key Point 3: Each peer has a public key. Public keys are short and simple, and are used by peers to authenticate each other.
They can be passed around for use in configuration files by any out-of-band method, similar to how one might send their SSH public key to a friend for access to a shell server.

For example, a server computer might have this configuration:

[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

[Peer]
PublicKey = TrMvSoP4jYQlY6RIzBgbssQqY3vxI2Pi+y71lOWWXX0=
AllowedIPs = 10.192.122.4/32, 192.168.0.0/16

[Peer]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
AllowedIPs = 10.10.10.230/32

=================================================
And a client computer might have this simpler configuration:

[Interface]
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
ListenPort = 21841

[Peer]
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = 192.95.5.69:51820
AllowedIPs = 0.0.0.0/0

In the server configuration, each peer (a client) will be able to send packets to the network interface with a source IP matching his corresponding list of allowed IPs. For example, when a packet is received by the server from peer gN65BkIK…, after being decrypted and authenticated, if its source IP is 10.10.10.230, then it’s allowed onto the interface; otherwise it’s dropped.

In the server configuration, when the network interface wants to send a packet to a peer (a client), it looks at that packet’s destination IP and compares it to each peer’s list of allowed IPs to see which peer to send it to. For example, if the network interface is asked to send a packet with a destination IP of 10.10.10.230, it will encrypt it using the public key of peer gN65BkIK…, and then send it to that peer’s most recent Internet endpoint.

In the client configuration, its single peer (the server) will be able to send packets to the network interface with any source IP (since 0.0.0.0/0 is a wildcard). For example, when a packet is received from peer HIgo9xNz…, if it decrypts and authenticates correctly, with any source IP, then it’s allowed onto the interface; otherwise it’s dropped.

In the client configuration, when the network interface wants to send a packet to its single peer (the server), it will encrypt packets for the single peer with any destination IP address (since 0.0.0.0/0 is a wildcard). For example, if the network interface is asked to send a packet with any destination IP, it will encrypt it using the public key of the single peer HIgo9xNz…, and then send it to the single peer’s most recent Internet endpoint.

Key Point: In other words, when sending packets,
the list of allowed IPs
behaves
as a sort of
routing table,
and when receiving packets, the list of allowed IPs
behaves as a sort of access control list.

This is what we call a Cryptokey Routing Table: the simple association of public keys and allowed IPs.

Any combination of IPv4 and IPv6 can be used, for any of the fields. WireGuard is fully capable of encapsulating one inside the other if necessary.

Because all packets sent on the WireGuard interface are encrypted and authenticated, and because there is such a tight coupling between the identity of a peer and the allowed IP address of a peer, system administrators do not need complicated firewall extensions, such as in the case of IPsec, but rather they can simply match on “is it from this IP? on this interface?”, and be assured that it is a secure and authentic packet. This greatly simplifies network management and access control, and provides a great deal more assurance that your iptables rules are actually doing what you intended for them to do.

DM Comment: Key Concepts to inwardly digest … comprehension is the road to success with WireGuard … KISS please.

EXTRACTED From: https://www.wireguard.com/

Did you mean each wireguard interface? Or each Device network interface ( aka vlans, subnets etc…), very confusing, Is a Wireguard a network interface ? or just an interface?

Key Point: In other words, when sending packets,
the list of allowed IPs
behaves
as a sort of
routing table,
and when receiving packets, the list of allowed IPs
behaves as a sort of access control list.

Described differently and I prefer,
The allowed IP address is used in a selection process for outgoing traffic (destination addresses) to enter the tunnel at the Local Site.
The allowed IP address is used in a filtering process for incoming traffic, to exit the tunnel at the Local site.
Therefore, especially at a Server Site, one needs to consider all flows of traffic.

What I did like was how you worded the cryptographic moments within the description.

Note: If one site is a single device, like an iphone or laptop, chances are the allowed IPs are mostly going to be of the outgoing variety and normally for internet traffic 0.0.0.0/0 which also covers any subnet that may exist at the remote site as well or any IP to configure the remote site as well.

For simplicity one may allow more traffic then one actually needs to through the tunnels (by allowed IPs and Routes) and then use MT firewall rules to limit actual flow more precisely.

Each WireGuard interface …
a vlan, subnet a device all can participate as long as they all are in the range of allowed IPs.
The set of allowed IPs defines what will be exposed … a device will have IP address … that device can reside in a subnet or a vlan that are covered by the range of allowed IPs. 404 you are making thing far more complicated than they actually are. KISS please ….
When you begin to overthink a concept you will become dizzy :face_with_spiral_eyes:

Of course you can achieve the same thing with IPsec by not using plain IPsec tunnels, but another tunnel type (IPIP,GRE,L2TP) on top of IPsec transport. Which is trivially easy to configure in RouterOS (not so much in plain Linux).
The advantage is that you can then run another routing protocol on top of this infrastructure, e.g. BGP or OSPF, and can obtain efficient and reliable routing even in a (partial) mesh network.
Furthermore, you can choose to have this in a different routing table than “main”, so you can use route marking and routing rules to direct the traffic as you wish.
(e.g. you may want to send some internet-bound traffic from a subsidiary to the main office where it will be filtered and scanned, and other traffic directly to internet on the subsidiary)

All of that is difficult to achieve with simple “we do all the routing” solutions (including plain IPsec tunnels).

@404
a network device like a printer has a IP address and resides in a net, subnet or vlan …. If the IP address of the printer is in the range of allowed IPs then WireGuard participants will be able to send print requests to that printer.
Another device like a PC also has a IP address and that PC sits inside LAN whose subnet is in the allowed IPs … that PC then can access any other system inside the WG tunnel assuming that is what has been permitted by the admin.

Defining a WG interface is based on what the requirements are … what is the purpose …. What do you need access to … who needs access … so once the requirements are understood then the system is built to suit the requirements. Many new people to VPNs completely abuse the privileges of the VPN and get into trouble quickly … then all hell breaks lose. A good admin forces discipline by determining Who, What, Where, How and Why.

Actually not, it was your imprecise terminology of “network interface” vice “wireguard interface” that was confusing. :slight_smile:

@404: … The Topic is WireGuard: Cryptokey Routing
When discussing INTERFACES … they ARE all related to WireGuard under this topic … absolutely not imprecise PERIOD … If the Topic was general in nature THEN I would accept your imprecise retort :slight_smile:

That part is okay, what is not okay and what you are shirking from stating is how to best use IP address for wG interfaces, that is really what I want to know.
Do you create one or more IP addresses for the wireguard interface to ensure capture of some or ALL peer IP addresses → you must admit this replaces any need for most additional routes!!
Do you use completeley different notation on the IP address for the wireguard interface, from any subnets existing on either side?

And explain to me this…
router1 wg1 ip address=192.168.10.1/30
router2 wg2 ip address=192.168.10.2/30

WHY someone insists that for router1 any IP Route I use referencing tunnel traffic should be
dst-address=remote subnet gwy=192.168.10.2 table=main

And on Router 2
dst-address=remote subnet gwy =192.168.10.1 table=main

In other words NOT the local IP address but one on the remote device, drives me bonkers…
Especially when I dont have to use IP address at all I can just use
R1
dst-address=remote-subnet gwy=name of WG1 interface table=main
R2
dst-address=remote-sbuntet gwy=name of WG2 interface table=main

Okay my mistake, I didnt realize that a wireguard interface was also considered a network interface by definition.
If it is, then the error is on my part.

I always thought Wireguard was a VPN not a network interface…

I think you meant to say virtual network interface LOL… Yup, you dont have me convinced yet,

This is the most illuminating read so far for me… digesting it now…
https://www.procustodibus.com/blog/2021/01/wireguard-endpoints-and-ip-addresses/

@404
Do you understand Cryptokey Routing and the example that was illustrated within that submission … nothing can be simpler …

Yes I do, I liked the explanation and now realize that wg is a virtual network interface…

The article I linked blesses everything I have been doing!!

If you’re happy then keep on trucking with what you are doing cause IMO you are a godsend to many on this forum whom you’ve helped. I tip my hat to You.

BTW anav, I hope that Tik will restore your other anav account … I do not understand why they suspended that account.

No worries mate back on wed some time, Just have to remember not to recommend other vendor products. I will still trash MT wifi but wont say what is better.
ON the flip side I am excited about AY 60hz stuff just announced. I may not need to lay future cable down the rocky hill to a future boat house with this kind of performance.
Which may never happen if Trump gets in power again, the US crumbles and the world is divided up between China and Russia, and you and I will be poor and at the mercy of dictators.

Yes, my problems with wireguard were getting stuck in subnetting and mask minutia and addresses and subnets noise. My gut was right all this time and wireguard is a flexible protocol and by following some basic rules most important of all being the crypto routing (that sindy described to me months ago) it will all work. As always, its understanding the OPs requirements that is usually the stumbling block and then the weird ass networks people have :wink: