VPN with WireGuard¶

Practical 3.10 vpn-with-wireguard-annex.pdf · PDF

Marta works at Tramuntana Apps. Today she is at home in Sóller. The office file server is 10.1.0.50. She types ping 10.1.0.50. What happens?

Use what you already know. 10.x is a private address: no router on the Internet has a route to it. And the office firewall drops anything new that comes from outside. The ping dies. Two bad ideas come to mind: port forwarding (opens the server to the whole world) or "send the file by e-mail". There is a better way, and companies use it every day.

Before anything new: the unit on one page¶

Before anything new, test yourself. Cover the right column and answer each line from memory. The Practical 3.10 sheet starts with the same list.

The lines you left blank are the ones to review before the exam.

An envelope inside an envelope¶

In SSH and TLS a packet was a postcard and encryption a sealed envelope. Keep that picture. Now draw two houses, Marta's home and the office, each with a router and a public address, and the Internet as a cloud between them.

1. Marta's PC writes a postcard to 10.1.0.50.
2. Her router does not send it as it is. It seals it (encrypts it) and puts it inside a second envelope, addressed to the office router's public address.
3. The Internet carries the outer envelope. It can only read the outer address.
4. The office router opens it, finds the inner postcard and delivers it inside its own LAN.

A VPN (virtual private network) carries private packets, encrypted, inside ordinary packets between two public addresses. The path between the two ends is called a tunnel.

flowchart LR
    subgraph HOME ["Marta's home"]
        PC["<b>Marta's PC</b><br>writes a postcard<br>to 10.1.0.50"]
        RH["<b>Home router</b><br>seals it in an envelope"]
    end
    subgraph OFFICE ["Tramuntana office"]
        RO["<b>Office router</b><br>opens the envelope"]
        SRV["<b>File server</b><br>10.1.0.50"]
    end
    PC --> RH
    RH ==>|"outer envelope:<br>public address to public address<br>(the tunnel)"| NET(["<b>Internet</b><br>sees only the outside"])
    NET ==> RO
    RO -->|"the original postcard"| SRV

With SSH, the envelope protected one conversation with one server. Here the envelope carries a whole network inside.

WireGuard¶

Older VPN programs are huge and hard to configure. Jason A. Donenfeld wrote a new one, WireGuard, first published in 2016 and described in a research paper in 2017. It has about 4,000 lines of code; the older programs have a hundred thousand or more. In 2018 Linus Torvalds called it "a work of art" next to them. Since Linux 5.6 (29 March 2020) it is part of the Linux kernel, and RouterOS has it since version 7.

Four words to learn:

A tunnel between two Linux machines¶

On the Practical 3.10 sheet you use the office lab and play both ends: one terminal in srv (the office), one in pc1 (Marta at home). The router r1 plays the Internet in the middle.

cd ~/lab/office && containerlab deploy -t office.clab.yml
docker exec -it clab-office-srv bash
docker exec -it clab-office-pc1 bash

On both ends, make a key pair and a WireGuard interface (wg0). On srv the tunnel address is 10.99.0.1/24; on pc1 it is 10.99.0.2/24:

cd /root; umask 077; wg genkey | tee wg.key | wg pubkey > wg.pub; cat wg.pub
ip link add wg0 type wireguard
ip addr add 10.99.0.1/24 dev wg0          # on pc1: 10.99.0.2/24
wg set wg0 listen-port 51820 private-key wg.key
ip link set wg0 up

• wg genkey makes the private key, wg pubkey derives the public one from it. cat wg.pub shows the public key to share.
• umask 077 makes the new files readable only by you: a private key nobody else may read.
• The tunnel is one more small network, 10.99.0.0/24, with its own addresses.

Then each end learns about the other. The public keys cross; the private keys stay:

srv$ wg set wg0 peer PC1_PUBLIC_KEY allowed-ips 10.99.0.2/32
pc1$ wg set wg0 peer SRV_PUBLIC_KEY allowed-ips 10.99.0.0/24 \
         endpoint 203.0.113.10:51820
pc1$ ping -c 3 10.99.0.1 ; wg show

Only pc1 needs an endpoint: it knows where the office is. The office learns Marta's real address when her first envelope arrives. The output of wg show on pc1:

interface: wg0
  public key: 9a6aKdM7d0ODkd8ALrnP3bewf4IIMEJr/+SojX8yNRI=
  private key: (hidden)
  listening port: 56978

peer: kJMY0w2sYVfr0RdmIK4iB99OPurmWOV27dTdprYo1xo=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.99.0.0/24
  latest handshake: Now
  transfer: 1.31 KiB received, 1.32 KiB sent

The line to look for is latest handshake. The handshake is the moment the two sides prove their keys to each other. No handshake line, no tunnel.

What does the Internet see?¶

In a third terminal, capture on the router in the middle while pc1 fetches the same page twice:

docker exec -it clab-office-r1 tcpdump -ni eth1 -A 'tcp port 80 or udp port 51820'
pc1$ curl http://203.0.113.10/      # outside the tunnel
pc1$ curl http://10.99.0.1/         # the same server, through the tunnel

The first curl appears on r1 as readable HTTP: the page, including its Wi-Fi password. The second appears only as lines like this, followed by noise:

IP 10.1.10.10.56978 > 203.0.113.10.51820: UDP, length 128

The router sees that two machines talk, and how much. Not what. Not even that it is a web page.

Two offices, two routers¶

Now the real case: Tramuntana Apps opens a second office. Your group (G) is one office; your partner group (H) is the other (1–2, 3–4, 5–6, 7–8). The class backbone 172.16.0.0/24 plays the Internet. With groups 1 and 2 as the example:

flowchart LR
    subgraph O1 ["Office of group 1 · LAN 10.1.0.0/24"]
        PC1["<b>PC</b><br>10.1.0.x"]
        R1["<b>R1</b><br>WAN ether1 172.16.0.1<br>wg-site 10.99.0.1"]
    end
    subgraph O2 ["Office of group 2 · LAN 10.2.0.0/24"]
        R2["<b>R2</b><br>WAN ether1 172.16.0.2<br>wg-site 10.99.0.2"]
        PC2["<b>PC</b><br>10.2.0.x"]
    end
    PC1 --- R1
    R1 ==>|"tunnel: UDP 13231<br>over the class backbone"| R2
    R2 --- PC2

Can a PC in 10.1.0.0/24 ping a PC in 10.2.0.0/24 today? No. The ping leaves masqueraded as 172.16.0.1, and group 2's firewall drops every new connection coming in through its WAN. That is exactly how two real offices are.

What each router needs:

1. A WireGuard interface with a UDP port (RouterOS uses 13231 by default). The router makes its own key pair.
2. An address on that interface: 10.99.0.G/24.
3. A peer: the partner's public key, its WAN address 172.16.0.H as endpoint, and as allowed addresses its tunnel address and its LAN.
4. A route: "the partner's LAN 10.H.0.0/24 is reached through the tunnel". If an older 10.H.0.0/16 route from the routing session is still there, nothing breaks: the /24 is more specific and wins.
5. One firewall rule: let the outer envelopes in (UDP 13231, input chain, above the rule that drops what does not come from the LAN).

Nothing here is new except the first line. Address, route, firewall rule: you have typed all of them before. A VPN is routing over a cable that does not exist.

On RouterOS¶

In your group, on the real MikroTik (G = your group, H = your partner):

/interface wireguard add name=wg-site listen-port=13231
/interface wireguard print                  (your public-key, for the partner)
/ip address add address=10.99.0.G/24 interface=wg-site
/interface wireguard peers add interface=wg-site public-key="PARTNER_KEY" \
    endpoint-address=172.16.0.H endpoint-port=13231 \
    allowed-address=10.99.0.H/32,10.H.0.0/24
/ip route add dst-address=10.H.0.0/24 gateway=wg-site
/ip firewall filter add chain=input action=accept protocol=udp dst-port=13231 \
    place-before=0 comment="wireguard"

Pass your public key to the partner as text (a shared document): 44 characters typed by hand never work. In WinBox: WireGuard in the left menu → + for the interface, tab Peers → + for the peer; then IP → Addresses, IP → Routes, IP → Firewall → Filter Rules (drag the new rule to the top).

Verify in order¶

It is the troubleshooting ladder again, for a tunnel. Stop at the first step that fails.

Then, alone, you repeat it by CLI on two virtual routers (containerlab deploy -t branch.clab.yml). On those CHR routers ether1 is the lab's management port, so the WAN moves to ether2 and the LAN to ether3. A blank CHR has no firewall, so it needs no input rule. The proof: on pc1, curl http://10.2.0.10/ shows the page of the other office.

Key takeaways¶

• A VPN carries private packets, encrypted, inside ordinary packets between two public addresses: an envelope inside an envelope, along a tunnel.
• WireGuard is small (about 4,000 lines), in the Linux kernel since 5.6 (2020) and in RouterOS v7. It runs over UDP.
• Each side has a key pair: the public key goes to the peer, the private key never leaves.
• A peer has an endpoint (where to send the outer envelope) and allowed addresses (which inner addresses live behind it).
• Site to site = interface + address + peer + route + one firewall rule. Verify in order: handshake, tunnel address, remote LAN.
• A capture on the path shows only UDP between the two ends: who and how much, never what.

Quick check¶

That closes the networking unit. Next, Unit 4 goes back inside one machine: where your files really live, on which disk, and how to keep them safe — Terminal survival and the directory tree.