I have set up a Brume 2 (GL-MT2500) as an OpenVPN server. I also have a Beryl that I intend to travel with, that hosts an OpenVPN client.
Currently, the VPN works in Layer 3 with the Brume 2 and Beryl LAN’s hosting their own subnets, plus a VPN tunnel IP range between them.
How can I configure my devices and VPN to use layer 2 and logically extend my Brume 2’s LAN subnet on to my Beryl, so that devices connected to the LAN of my Beryl have the same LAN subnet IP addressing as my Brume 2?
The GL.inet forums mention this problem many times, and there’s documentation I believe showing TAP functionality (for firmware 3.x releases), however I’m currently using 4.x for both my devices.
This feature is scheduled to be added to the firmware in version 4.5.0 under the name openvpn tap-s2s, and you may be able to try it out with snapshot firmware next week. https://dl.gl-inet.com/?model=mt2500&type=snapshot
But Beryl’s 4.5 snapshot firmware will have to wait a while
I’ll be interested in seeing how this is implemented. I have only found one scenario when TAP mode was necessary. For everything else TUN has been superior and much easier for me to wrap my head around.
I have s2s going in TUN mode between my second residence and my first. It is split tunneling on both sides. My first residence has an Asus router that supports two server instances, one TUN and one TAP. The TAP instance is connected by a third router with a TAP client, to which one and only one device is connected, not in split tunnel, with no need for it to connect to anything other than one device on the first subnet. It is stable, but a lot of blood was lost in the process.
Among other things, setting aside wasting bandwidth, with a single client device you have to either run a single DHCP server, and accept that no device on the client side will work until the tunnel is up, or run a server on each side, each in its own range, with some scripting to prevent each from responding to requests on the other side. You have to figure out split tunneling, if it can be done, or give that up. You have to accept that TAP is being deprecated, and when DCO is available with its speed enhancements, you will have to do something else. And wireguard with its current speed advantages won’t work. Unless you have another server in the mix, you won’t be able to connect other devices as clients.
My hat will be off to the engineer who can nail this feature, but a user really has to consider why this is a good idea.
DCO and TAP are incompatible, but I highly doubt OpenVPN will deprecate TAP any time soon. And with OpenVPN also being able to use Chacha20-Poly1305 encryption and GL-iNet’s devices becoming more and more powerful (MT2500 already doing 150 Mbps OpenVPN). I actually rarely run into that being the bottleneck.
I also think GL-iNet will just make TAP work, but not do anything fancy like split tunneling, because I frankly believe that would be next to impossible.
When talking TAP, we’re talking sending packets to MAC-adresses, not IP with its routing. On most switches (which is basically what OpenWRT will be doing when setting up a TAP-OpenVPN; bridge-interface between LAN net and TAP-OpenVPN) there’s not much going on. If a switch is not connected to any upstream router, not much will happen when you plug in a device into that switch. Once it is plugged into a router, things magically start working. I expect site-to-site TAP networking to basically act the very same way for the remote side.
There are rare cases where you want broadcasts to reach the other side of a VPN tunnel, but you’re right that most likely things all the things most people want to do also happily work on OpenVPN DCO or TUN (and Wireguard).
To be honest I have not seen any OpenVPN 3.0 daemon branches yet, so I wonder how you know OpenVPN 3.0 drops TAP-mode. I know 2023.06.13 – Version 2.6.5 is latest as far as I know and that still does TAP. Current master (future 2.7?) also still has it.
Traffic going through a OpenVPN TAP-interface is of course being encrypted.