[resolved] bridge "branch office" WiFi to "headquarters" LAN

linuxbastler

Hi there!

In short:
I am trying to use an openVPN setup with bridges on each side of the tunnel to get a client-side wifi to "extend" the LAN on the server side.

All bridging, there is one subnet shared among both locations.

The tunnel is established and the wifi clients in the "branch office" can ping the headquarter's VPN-server and use it as default gateways.

The strange part:
- the two gateway machines (the two end points of the VPN tunnel) can ping all other machines.
- each client can ping the remote gateway machine through the tunnel.
- the clients at the "branch office" can happily use the headquarter's VPN server as default gateway
- clients cannot reach machines connected to the network behind the remote gateway machines

Now comes the long / detailed version!
The subject line is not entirely accurate, but was used for brevity. Here is the entire setup:

I have a fast fibre internet connection at home. My home network consists of a standard SOHO router with integrated WiFi access point and DHCP server. As is customary for these devices the wired and wireless interfaces are bridged, so all machines in my home share the same subnet.

I have a few machines at home attached to the network, providing different services (samba/dlna/VoIP/ftp/SVN/IP-TV/...).

I travel a lot and usually carry several wifi-enabled devices (laptop, smartphone, eBook-reader, tablet,...) with me. Since internet access at hotels is extremely regulated, the idea now is to use openVPN and my laptop's wifi card to "extend" my home wifi network to my hotel room, so I can use all the services I have at home when I'm abroad, without having to reconfigure all my devices.

Data for the home network:
- VDSL router
- openVPN server on the router, listening on WAN-interface
- eth0 (wired), wlan0 (wireless), beta-vpn (openvpn tap interface) all bridged as "lan"
- DHCP server in the SOHO router used to server addresses to the bridge
- router is default gateway for all machines at home
- local ip address is 192.168.13.13 netmask 255.255.255.0 default gateway 192.168.13.13 for entire network.
- the local network is called "beta", hence the naming on various related interfaces

Data for the laptop used to "call home":
- openvpn client
- internet uplink established though whatever means available (3G card/ second wifi card/ wired network) This is used to establish the VPN connection to my home VDSL.
- "beta-vpn" (openvpn tap interface) bridged with "beta-wpa" (atheros wifi card in master mode with hostapd, providing a wifi access point for all other devices) as br0
- all devices attached to "beta-wpa" are to use my home router (192.168.13.13) as default gateway, to avoid the hotel's restrictions on using VoIP, icq, etc.

What works:
- the hostapd part (setting up the wifi in my hotel room)
- DHCP through the tunnel (all my mobile devices connecting to my wifi at the hotel receive an IP address from my home DHCP server)
- internet access for my mobile devices through the tunnel (I can access Google, chat on ICQ, ...).

What does NOT work:
Machines on each side of the tunnel can see/ping/access the gateway machine directly at the other end of the tunnel, but not any machines on the remote network segment. This is bi-directional.

Examples:
- I can ping my home router from my smartphone at the hotel (which is connected to the laptop's wifi), but I cannot access my desktop PC.
- I can ping my laptop at the hotel from my desktop PC at home, but I cannot ping the smartphone attached to it via hostapd.

- Disabling firewalls on both sides doesn't help.
- since I can access the internet through the tunnel my suspicion is it's openVPN, hiding the local part of the network from the remote part of the tunnel.

is there anything I'm missing? Please help!

While we're at it:yes, I am aware of the drawbacks of bridged networks as opposed to routed networks. Many of the protocols I wish to use through the VPN tunnel however are dependent on extremely large dynamic port ranges, broadcast messages and other ugliness which is extremely annoying to route reliably, so I will most definitely go with bridged networks if at all possible. Creating routed networks is not an option!

Also, I use TCP even though it's slower, to be able to connect through http(s) proxies.

Os on the server is some kind of stripped down embedded linux (it's a AVM "Fritz!Box 7390"), ubuntu 12.04 on the laptop.

server side config (on my router at home):

port 443
proto tcp-server
dev beta-vpn
dev-type tap
dev-node /var/tmp/tun

ca ./keys/ca.crt
cert ./keys/beta.crt
key ./keys/beta.key
dh ./keys/dh2048.pem
tls-auth ./keys/ta.key 0 # This file is secret

server-bridge
client-to-client
hand-window 300    # allow a longer time for initial handshake to accomodate for long processing time of large keys on slow devices or over slow connections
client-config-dir ccd
cipher AES-256-CBC
max-clients 5
persist-key
persist-tun
tun-mtu 1500
mssfix

bridge name     bridge id               STP enabled     interfaces
lan             8000.0024fedf1176       no              eth0
                                                        ath0
                                                        ath1
                                                        beta-vpn

on the client side (laptop at the hotel):

client
dev beta-vpn
dev-type tap
proto tcp-client
remote my.home.lan 443
resolv-retry infinite
nobind
verb 3
cipher AES-256-CBC
persist-key
persist-tun
float
remote-cert-tls server
ca /home/bastler/openVPN/beta/ca.crt
cert /home/bastler/openVPN/beta/alpha.crt
key /home/bastler/openVPN/beta/alpha.key
tls-auth /home/bastler/openVPN/beta/ta.key 1
# daemon
script-security 2
mssfix

bridge name	bridge id		        STP enabled        interfaces
br0	     	8000.1a6d312aef53      no		           beta-vpn
                                                        beta-wpa

Mimiko

is there anything I'm missing?

Did you ckecked on server and client that forwarding is enabled? As you are using some AVM "Fritz!Box 7390", may be it can't do forwarding?

linuxbastler

what exactly do you mean by "forwarding"?

you mean that the kernel should not drop packages it received that are addressed to another machine? something like this?

echo 1 > /proc/sys/net/ipv4/ip_forward

Yes, it's enabled on both the router and the laptop. It makes no difference if I disable it however, because the packet forwarding should be handled by the bridge before the packet even enters the kernel's netfilter.

Also, the Laptop itself and the router at home (I have shell access to it) can access/ping all machines on the network, so the router at home is forwarding these packages just fine.

The router box can do forwarding. In fact I had a setup running a few days ago where only the server-side network was bridged, and the client-side network was NATed onto a different subnet. This worked fine, but I was looking for the "bridged on both sides"-solution to avoid the problems in routing VoIP and DLNA etc.

One other observation: the wifi card on my laptop has an "activity"-LED. I don't know how reliable it is, but it blinks when I ping google from the smartphone at the hotel (this connection passes through the laptop, the VPN, and the home router to the internet). It also blinks when I try to ping the smartphone from the home router (which works). It does not blink when I try to ping the smartphone at the hotel from my desktop machine at home (which does not work).

This might suggest that the ping requests never reach the wifi network through the tunnel....

linuxbastler

I solved my problem!

For all interested:

remember how in a lot of openVPN bridging howtos there's a note about the "Spanning Tree Protocol" (handling inter-bridge communication), saying that if this is your only bridge in the network you can save a few ressources by disabling it, since the single bridge has no one to talk to anyway?

Well, the setup described here has more than one bridge! STP is what tells one bridge about the network topology on the far side of the other bridges in the network, so layer-2 can route packages properly...

If you have more than one bridge on the network, you must activate Spanning Tree Protocol on all bridges!

A little practical note:

Especially if established through 3G or analog land lines (yes, they still exist!) the VPN tunnel can be considered a slow link, so propagation of STP information across the distributed network may take a while. If you cannot ping a freshly associated station through the bridge right away, give it a few seconds. You can speed up the process by sending some broadcast packages (which will reach all stations on the net) from the freshly associated station. This will make all bridges quickly notice there's a new device online and trigger an update of the appropriate MAC routing tables.