Transparent tunnel between interfaces on remote hosts

Question

I need to make a solution which will work as a network switch with two ports: one port located in one country and second port is in another country.

              +------------ Virtual switch ----------------+
+---------+   |   +-------+    +----------+    +-------+   |   +--------+
|Client A |<--+-->| BOX 1 |<-->|VPN server|<-->| BOX 2 |<--+-->|Client B|
+---------+   |   +-------+    +----------+    +-------+   |   +--------+
              +--------------------------------------------+

Client A and Client B shoud feel it like usual layer 2 switch. VPN connection between two boxes is OpenVPN. So I need to forward Ethernet frames somehow over the VPN tunnel between two boxes. Box 1 and 2 running Debian jessie. I hope not to write my own software for it :) Can anyone suggest possible solutions?

P.S. It is needed to connect two pieces of hardware which is designed to work only in LAN.

UPD: I've installed 4 VMs to simulate such setup (vpnserver was omitted):
- All machines are debian boxes
- Box 1 and Box 2 have GRE tap tunnel between them (Ethernet over IP)
- On Client A local interface bridged with gretap interface: bridge has address 10.0.0.253
- On Client B local interface bridged with gretap interface: bridge has address 10.0.0.254
- Client A has static IP 192.168.1.1
- Client B has static IP 192.168.1.2

From Client A I'm sending ICMP Echo request to 192.168.1.2 and I can see ARP request "Who has 192.168.1.2 tell 192.168.1.1" on bridge on Box 1, on bridge on Box 2 and on Client B. But ARP response is visible only on Client B. So ARP response not going back to Box2 somehow. And all networking between 10.0.0.253 and 10.0.0.254 works well. So, I suppose that problem caused by bridging.

UPD2: Now I removed GRE tap tunneling and established regular network between Box 1 and Box 2. When I created bridges, ping started working. What could cause problem when doing GRE tunnel?

Solution: I finally configured everything in VMs with GRE-TAP. I've used GRE-TAP tunnel over regular network between Box 1 And Box 2. And then I bridged tunneling interface with local interfacec on each Box. Below is my steps:

Box 1

ip link add tunnel0 type gretap remote 192.168.0.2 local 192.168.0.1
brctl addbr br0
brctl addif br0 eth2  # eth2 - is a local interface on Box 1
brctl addif br0 tunnel
ip addr add 10.0.0.253 dev tunnel0
ip link set br0 up
ip link set tunnel0 up

Box 2

ip link add tunnel0 type gretap remote 192.168.0.1 local 192.168.0.2
brctl addbr br0
brctl addif br0 eth2  # eth2 - is a local interface on Box 2
brctl addif br0 tunnel
ip addr add 10.0.0.254 dev tunnel0
ip link set br0 up
ip link set tunnel0 up

Thanks to all!

Answer 1

I haven't tried this myself, but I know you can use gretap to tunnel layer 2 (ethernet) over layer 3 (ip). According e.g. to this blogentry, you set up one gretap interface at each end and bridge it with your ethernet interface. If I understand everything correctly, in the example 172.31.0.1 should be the address of the VPN endpoint on Box 1, and 172.31.0.2 the address of the VPN endpoint on Box 2. 10.10.10.1 is the local LAN address for Box 1, and 10.10.10.2 the LAN address for Box 2.

Box 1:

ip link add gretap0 type gretap local 172.31.0.1 remote 172.31.0.2
ip link set dev gretap0 up
ip link set dev eth0 up
brctl addbr br0
brctl addif br0 gretap0
brctl addif br0 eth0
ip addr add 10.10.10.1/24 dev br0
ip link set br0 up

Box 2:

ip link add gretap0 type gretap local 172.31.0.2 remote 172.31.0.1
ip link set dev gretap0 up
ip link set dev eth0 up
brctl addbr br0
brctl addif br0 gretap0
brctl addif br0 eth0
ip addr add 10.10.10.2/24 dev br0
ip link set br0 up

You may need to tweak MTU settings. I can't test this setup, so you may also need to tweak other things.

Edit: Here is an article that explains the MTU issues, apparently it's a bit involved. It may be easier in your case if you can control the VPN MTU settings.

Answer 2

This is not very difficult, because all you are asking for is that all L2 traffic be able to pass from one network to another, which is a standard feature of a bridged OpenVPN connection. This means that:

1. either you configure the OpenVPN server (and the two clients) to setup a bridged OpenVPN connection (and remember to allow connections from client to another client via the client-to-client instruction in the server configuration file), ...

2. or you do away with the middleman, and directly connect Box1 and Box2, as discussed for instance here or here.

In either case, you need to work on the DHCP and routing in both LANs, because both of them must belong to the same broadcast domain. For instance, we may decide that the subnet we use is 192.168.0.0/23, with the DHCP server on LAN1 dishing out addresses in the range 192.168.0.0/24, and the DHCP server on LAN2 dishing out addresses in the range 192.168.1.0/24.

Then you need to adjust routes. Suppose Box1 is a pc in LAN1 with address 192.168.0.121, and Box2 is a pc in LAN2 with IP address 192.168.1.173. Then on the gateway of LAN1 you need to add the route:

ip route add 192.168.1.0/24 via 192.168.0.121 

while on the gateway of LAN2 you need to add:

ip route add 192.168.0.0/24 via 192.168.1.173

This generates some amount of intra-site L2 traffic, which you may find annoying. I have a three-site configuration like this, and I have no problem with the amount of traffic, and 100Mb/s connections, but YMMV. If you want to limit the amount of L2 traffic crossing the OpenVPN, you may use ebtables on Box1 and Box2.

That's the only way I know to realize what you asked for.