This note describes how to connect two networks/devices/VMs over public network using Wireguard with Layer 2 support (ARP, IPv6 link-local, etc).
This can also be achieved using SSH and its "tap" tunnel, however, it does not provide the same level of latency and bandwidth as full-blown VPN such as Wireguard.
In addition, this note describes how to tunnel Wireguard over TCP connection. This may be of use if you encounter firewall in-between so, for instance, you can use TCP port 443 only.
Let's draw a network diagram of what we would like to have in as a result.
Host on private LAN Host on the Internet
+---------------------------------+ +-------------------------------+
| brtun bridge | | brtun bridge |
| +-------------+ | | +--------+ |
| | ethX gretun |<->wg0<->udp2raw | <-Internet, TCP 443-> | udp2raw<->wg0<->| gretun | |
| +-------------+ | | +--------+ |
+---------------------------------+ +-------------------------------+
brtun: 192.168.0.200/24 brtun: 192.168.0.50/24
wg0: 12.12.12.2/24 wg0: 12.12.12.1/24
gretun: 12.12.12.2->12.12.12.1 gretun: 12.12.12.1->12.12.12.2
Distinguishing between server and client here is based on the answer to the question: who can connect to Wireguard listener socket.
Generating a key:
wg genkey | tee wgkeyprivs | wg pubkey > wgkeypubs
Creating a Wireguard interface, setting the private key and a unique private IPv4 address:
ip l a wg0 type wireguard
wg set wg0 private-key ./wgkeyprivs
ip a a 12.12.12.1/24 dev wg0
In case we want Wireguard over TCP, we have to decrease MTU:
ip l set dev wg0 mtu 1200
Configuring peer's public key and setting interface up (you can restrict allowed-ips to the range you want):
ip l set dev wg0 up
wg set wg0 listen-port 51820 peer $(cat wgkeypubc) allowed-ips 0.0.0.0/0
Creating GRETAP interface which will provide Layer 2 over our Wireguard tunnel:
ip l a gretun type gretap local 12.12.12.1 remote 12.12.12.2
ip l s gretun up
Configuring a bridge which includes GRETAP interface. This step is in fact optional, but it allows you some flexibility: you can assign an IP address to this bridge interface and/or you can add additional interfaces to this bridge.
ip l add name brtun type bridge
ip l set dev brtun up
ip l set gretun master brtun
Let's assign an IP address from the target network to this bridge:
sudo ip a a 192.168.0.51/24 dev brtun
If we want Wireguard over TCP, launch UDP2RAW listener which will do its magic. You can get UDP2RAW from this Git repo: https://github.com/wangyu-/udp2raw-tunnel/releases/
./udp2raw_amd64 -s -l YOUR_PUBLIC_IP:443 -r 127.0.0.1:51820 -a --fix-gro
Client is very similar to the server described above.
Generating a key:
wg genkey | tee wgkeyprivc | wg pubkey > wgkeypubc
Creating a Wireguard interface, setting the private key and a unique private IPv4 address:
ip l a wg0 type wireguard
wg set wg0 private-key ./wgkeyprivc
ip a a 12.12.12.2/24 dev wg0
In case we want Wireguard over TCP, we have to decrease MTU:
ip l set dev wg0 mtu 1200
Configuring peer's public key, endpoint address and setting interface up (you can restrict allowed-ips to the range you want):
ip l set dev wg0 up
wg set wg0 listen-port 51820 peer $(cat wgkeypubs) allowed-ips 0.0.0.0/0 endpoint YOUR_PUBLIC_IP:51820 persistent-keepalive 15
In case you want Wireguard over TCP, set endpoint address to a localhost interface:
wg set wg0 listen-port 51820 peer $(cat wgkeypubs) allowed-ips 0.0.0.0/0 endpoint 127.0.0.1:7777 persistent-keepalive 15
Creating GRETAP interface which will provide Layer 2 over our Wireguard tunnel:
ip l a gretun type gretap local 12.12.12.2 remote 12.12.12.1
ip l s gretun up
Configuring a bridge which includes GRETAP interface.
ip l add name brtun type bridge
ip l set dev brtun up
ip l set gretun master brtun
Let's add a physical interface belonging to a LAN network to the bridge and start DHCP client:
ip l set ethX master brtun
dhcpcd ethX
If we want Wireguard over TCP, launch UDP2RAW listener on the localhost interface which connects to the corresponding public listener.
./udp2raw_amd64 -c -l 127.0.0.1:7777 -r YOUR_PUBLIC_IP:443 -a --fix-gro
That's it. Now you will have Layer 2 connectivity between two separated machines over Wireguard VPN (optionally, over TCP). Enjoy your ARP and IPv6 link-local experience.
Hello @zOrg1331, @SandeepAthiyarath
@zOrg1331 I asked you some questions a couple of weeks ago and I'm now reporting back to you. @SandeepAthiyarath I hope my findings can be useful for you.
I currently have a Wireguard + GRETAP system working successfully and I'm going to document here what I did. My objective was to connect 2 sites -- one on each side of the Atlantic ocean -- as if they were on a single LAN. A key requirement for me was that broadcast traffic be seen on both sides. There was some trial and error to get this to work, but now that it's working, I'm getting at least 4x the performance I used to get with OpenVPN TAP, and significantly better than what I get with Zerotier. I'm getting 200 Mbps in both directions between the two sites (my Internet speed in North America is the limiting factor). Here is a step-by-step explanation of what I did.
BACKGROUND
In my network, both sides are on the same subnet -- 192.168.15.0/24. Each side has its own DHCP server. However, the addresses given out by Side A's router (192.168.15.1) go from .100-.169 and by Side B's router (192.168.15.2) from .170-.254. Using ebtables, I block DCHP requests from going over the VPN, so each side only sees its local DHCP server (I explain this at the bottom). I have a number of static IP addresses in use on either side but they are all in the 10-99 range.
I have dedicated Wireguard gateway servers on each side. The physical hardware for each server is a $160 Beelink Intel Quad-core with 1 x 1 Gb Ethernet port. The servers are running Ubuntu 22.04 LTS and they are using the default "Netplan" system for configuring everything related to networking. I realize most distributions don't use Netplan, but I find Netplan very sensible and easy to understand because it puts all network configuration in one single file (although it's a little fussy when it comes to proper indenting).
One other thing. I use UDP port 52001 for Wireguard on both sides, so on each side I have to forward that port from my router to the Wireguard server. So, here's how I set everything up (with much thanks to @zOrg1331 for helping me get started). My instructions assume you have already installed the Wireguard tools packages.
STEP ONE -- GENERATE WIREGUARD KEYS
NOTE: The keys used below are not my keys. I found them in some other random Wireguard example.
Side A -- North America
Side B -- Europe
In the next step, we will copy and paste Side A's public key into Side B's Wireguard configurationso that Side B can gain access to Side A. And vice versa.
STEP TWO -- CONFIGURE NETWORKING FOR WIREGUARD
On Side A -- North America -- modify /etc/netplan/00-installer-config.yaml and apply changes.
I have only one physical Ethernet port (enp1s0) on the Beelink computer that I use for Wireguard here, and I want it to have a static address of 192.168.15.20 and I want that to be part of a bridge br0. I want to set the IP address and default gateway (the LAN address of my American router) ONLY on the bridge interface. The physical interface should NOT have an IP Address. I also want to create the Wireguard tunnel so that it will have the address 172.16.0.1/24 and automatically connects to the European side.
Contents of /etc/netplan/00-installer-config.yaml
To apply, run the command "sudo netplan apply"
On Side B -- Europe -- modify /etc/netplan/00-installer-config.yaml and apply changes.
I have only one physical Ethernet port (enp1s0) on the Beelink computer that I use for Wireguard here, and I want it to have a static address 192.168.15.21 and I want that to be part of a bridge br0. I want to set the IP address and default gateway (my European router) only on the bridge. I also want to create the Wireguard tunnel so that it will have the address 172.16.0.2/24 and automatically connect to the European side.
Contents of /etc/netplan/00-installer-config.yaml
To apply, run the command "sudo netplan apply"
STEP 3 CONFIRM THAT WIREGUARD IS RUNNING AND CONNECTED TO THE PEER ON THE OTHER SIDE
On the European side if I run "sudo wg show" I see:
Once Wireguard is running on both sides, I should be able to ping from one Wireguard server to the other across the Atlantic. For example, from 172.16.0.1 I get:
vpnadmin@andyvpntorre:/etc/netplan$ ping 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=130 ms
64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=126 ms
64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=134 ms
64 bytes from 172.16.0.2: icmp_seq=4 ttl=64 time=138 ms
VERY IMPORTANT! Note, at this point, from the Wireguard server at 192.168.15.20 I cannot ping the Wireguard server at 192.168.15.21. In other words, the Wireguard servers don't know anything about how to cross the Atlantic on the 192.168.15.0/24 network. But they soon will.
STEP 4 -- CREATE GRETAP INTERFACES AND ADD THEM TO THE BRIDGE br0
I haven't yet tried putting this in my netplan configuration (I will soon and I'll come back here and edit this post) so after I have Wireguard running properly on each side and connected to the other side, I now create the GRETAP interface so that my Ethernet packets will flow from any computer on Side A to any computer on Side B (including from 192.168.15.20 to 192.168.15.21).
On Side A run the following commands:
sudo ip link add gretun type gretap local 172.16.0.1 remote 172.16.0.2 ignore-df nopmtudiscThis creates a virtual interface called "gretun" of the type "gretap". Packets will go from local IP address 172.16.0.1 to remote address 172.16.0.2. Note the addition of the two options "ignore-df" and "nopmtudisc". Without these, I found that packets larger than 1354 bytes could not get through the tunnel. For instance, web pages won't load across the tunnel. This is due to large packets not getting fragmented into pieces that are small enough to go through the tunnel. The large packets just get dropped without those options.
ip link set gretun upThis brings up the gretun interface
ip link set gretun master br0This adds the gretun interface to my bridge "br0"
ip link set gretun mtu 1500The default MTU that gets created for the GRETAP interface that we named "gretun" is too low and even with the "ignore-df" and "nopmtudisc" options. Setting the MTU to 1500 ensures that all normal network packets will get through.
On Side B, do the same thing except swap the IP addresses:
Assuming you have bridge-utils installed, you should see the following when you run the command "brctl show"
STEP 5 -- BLOCK DHCP REQUESTS FROM CROSSING OVER THE VPN
On the Wireguard server on each side, I run the following commands:
I will eventually put this into a script that runs a minute or so after the Wireguard-GRETAP bridge is up and connected.
FINAL NOTES