Bridged Mesh

Mordenkainen

Is there a way to configure a bridged mesh with OpenVPN?

We currently have 6 LAN's VPN'd together via bridging so that all are part of the same subnet. We used a bridged configuration instead of routed because we have several applications (games, NETBios) that use broadcasts to discover each other. This was done using OpenVPN running on DD-Wrt routers.

Everything works fine, but there are some performance issues associated with all the traffic being transferred through the OpenVPN server for client to client transfers.

We would like to switch to a mesh topology where if Client A needs to talk to Client B, it does not have to go through Server A to get there. I know this can easily be done in a routed configuration, but then our applications would not work due to broadcasts not being routed.

Is there a way to configure the VPN to allow a bridged configuration where each client has a connection to every other, or perhaps a way to use a routed configuration but allow broadcasts to reach everyone?

An example of the configuration used on clients and server can be found here: http://www.dd-wrt.com/wiki/index.php/OpenVPN_-_Site-to-Site_Bridged_VPN_Between_Two_Routers
The only major change from the example listed there is that we are using a Class B subnet of 192.168.x.x instead of a Class C as in the example.

TIA
Morden

EDIT - Reposted here because I realized I posted it in the wrong forum. Sorry!

somms

--client-to-client

Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router. The --client-to-client flag tells OpenVPN to internally route client-to-client traffic rather than pushing all client-originating traffic to the TUN/TAP interface. When this option is used, each client will "see" the other clients which are currently connected. Otherwise, each client will only see the server. Don't use this option if you want to firewall tunnel traffic using custom, per-client rules.

FWIW: Using the above config on my router flashed w/DD-WRT...

krzee

somms: actually, --client-to-client does not solve his issue.
his clients DO see eachother, he is hoping to find a way to not force traffic to travel from A to C through B, when B is the server.
--client-to-client only has to do with firewalling...
with this option packets from 1 client to another are routed inside the server process. without it packets leave the server process, hit the kernel (firewall, routing table) and if allowed by firewall and routed back to server process, they go to the client. you use this option when you do not want to use selective firewall rules on what clients can access things behind other clients.

Mordenkainen: I do not *think* this is possible, because there is no way for your machine to know *which* vpn to send the traffic to for any specific client/client lan. In layer3 we have routing tables for this... in layer2 you just broadcast to everything... in fact a mesh would leave you sending the traffic to ALL vpns i believe.
disclaimer: I do not normally support bridges, as I do not use them myself. I may or may not be correct, but what im saying seems logical to me

krzee

note, if you only needed netbios, you could simply run WINS instead. If you ONLY need broadcast traffic, you can check out bcrelay, which can be stolen from the pptp source tree...
then you could use tun

Mordenkainen

Thanks! I'll check out bcrelay.

supnobita

@ krzee:
please talk more about bcrelay, how can i combine with openvpn ?

Thank a lot