I was recently asked to figure out how to configure an L2 tunnel for a bridge between two remote LANs, and I was amazed at how few convenient solutions I could find. Previously, I was not interested in this topic and naively believed that any adequate VPN protocol can catch broadcast packets and forward them over a regular L3 tunnel. Unfortunately, there are no universal solutions out of the box. There are several protocols and tools for them, most of which work in very limited conditions or are generally declared deprecated. I will share the most pleasant option further.
Why exactly L2?
I asked this question in the first place: I rarely work with network peripherals, and it seemed to me that for a long time all the equipment has been able to walk along L3. No matter how it is: someone needs access to office printers, someone to video recorders, and someone just wants to hack to death with a friend in a LAN duel - without leaving home, of course. Also very attractive is the idea of shared / network folders in the office, accessible from home, especially during the period of general removal.
At the same time, among the developers of VPN clients, L2 bridges are for some reason considered to be something like a strange whim of one or two percent of users, which by and large is not needed by anyone. The situation is completely different in industrial networks, where there is a lot of outdated or poorly compatible equipment, and the L2VPN concept (represented by a bunch of other abbreviations) is implemented at the network and provider equipment level.
Technology
There are a lot of them, and they all work with weirdness and limitations:
- For example, the Layer 2 Tunneling Protocol (L2TP) should, judging by the name, provide support for OSI L2, including broadcast forwarding. But no, the generally accepted L2TP + IPsec bundle does not allow bridging networks at the L2 level!
- PPTP - has become a meme due to major vulnerabilities, is now somehow fixed, but has no relation to L2.
- MPLS — «» . , RouterOS ( , ).
- PPPoE PPPoEoE , . PPPoE , Cisco.
- EoIP L2VPN made right, , . PPTP, GRE, NAT.
And then I was surprised to find that a real Ethernet Bridging can ... OpenVPN!
We often use a personal or work VPN, many have it turned on on an ongoing basis to bypass blocking (although this trend is declining after the Telegram block is removed). In my work tasks, I also constantly use remote hosts for development, and almost always use OpenVPN. For a long time I did not understand why I need a bundle of OpenVPN Access Server + OpenVPN Connect on the client. For my tasks, I always had the classic version with manual editing of configs, and the dedicated admins and GUI seemed inappropriate in a slender thin client. But it turned out that the interface for setting up the bridge is much more convenient than the sheets of configs in the terminal, although not everything is perfect with it.
Customization
The fact is that Access Server (AS) came out as a paid and rather expensive product, so they diligently crammed all kinds of goodies into it, just to buy it. Thus, a menu sub-item appeared in the web admin panel, allowing you to select the network mode (L2 bridging / L3 routing), and after a while it was quietly cut from there for the same reason "no one needs it." However, the bridging functionality itself and the corresponding scripts were not deleted and they can still be customized.
Installation
We need a server or virtual machine. The image for it is on the download page , and we will continue to analyze the case with installation on a server under Ubuntu 18.04:
apt update && apt -y install ca-certificates wget net-tools gnupg
wget -qO - https://as-repository.openvpn.net/as-repo-public.gpg | apt-key add -
echo "deb http://as-repository.openvpn.net/as/debian bionic main">/etc/apt/sources.list.d/openvpn-as-repo.list
apt update && apt -y install openvpn-asAfter installation, the server will rise on its own, you will see the following message:
+++++++++++++++++++++++++++++++++++++++++++++++
Access Server 2.8.4 has been successfully installed in /usr/local/openvpn_as
Configuration log file has been written to /usr/local/openvpn_as/init.log
Access Server Web UIs are available here:
Admin UI: https://185.209.31.165:943/admin
Client UI: https://185.209.31.165:943/
+++++++++++++++++++++++++++++++++++++++++++++++
You must immediately specify the password for the admin account:
passwd openvpnThen you can open the admin panel in the browser (at: 943 / admin, as indicated above), log in as the openvpn user with the specified password and configure the server.
AS is free to use by two users, then you can add it only for $ 18 / month per user, so it's better to immediately design your processes for using the tunnel by two clients.
Bridging back
cd /usr/local/openvpn_as/scripts
./sacli --key "von.general.osi_layer" --value "2" ConfigPut
./sacli startIf everything went well, the output json will contain the following:
{
"errors": {},
"last_restarted": "Thu Jul 2 00:07:37 2020",
"service_status": {
"api": "on",
"auth": "on",
"bridge": "on",
...
}
}In the admin panel, the status "OSI Layer: 3 (routing / NAT)" will change to "2 (bridging)"
NB: in recent versions, information about L3 may remain with the bridge enabled. Why - I did not understand, safe in this regard versions around 2.4
Actually, this know-how ends, then you just need to configure a server for yourself, get a second user through the same web interface and log in to the user page on port 943 (without / admin). There will be links to download OpenVPN Connect clients for all platforms with a baked config for connection (except for mobile applications, you will have to drive in the address manually, and then everything will be installed by itself).
After successfully connecting and bridging clients, an L2 tunnel with TCP / UDP traffic will be available. Clients can act as a nat for the internal network, this is also configured in the admin panel.
