Hi, On 28/11/17 20:47, Martin Buck wrote: > Hi, > > I'm trying to build something like a distributed Ethernet switch using > OpenVPN in bridged/TAP mode. Each OpenVPN client as well as the server > features a LAN with several nodes, connected to OpenVPN's TAP interface > using a Linux software bridge.
Does it mean each node is a 'OpenVPN node'? To be honest, I think I can safely claim that OpenVPN is not designed for this kind of scenario. > > So far, so good. Problems start when LAN nodes start to roam (potentially, > they may move freely between all LANs). Differences to a normal Ethernet > switch (where "roaming" between different ports wouldn't cause problems) I > noticed so far: > > 1. On the VPN server, there's no flooding towards VPN clients for frames > with an unknown destination address. Instead, such frames are dropped. This should probably stay like this, otherwise any client could just flood the entire network by simply sending packets with random MAC addresses. > 2. Addresses of LAN nodes behind VPN clients which are learned by the VPN > server are only forgotten when the VPN client disconnects. There's no > time-based expiry after some time of LAN node inactivity. As I stated above, this is likely by design because openvpn was not meant for such a dynamic scenario. > 3. On the VPN server, there's no (source) address learning on the TAP > interface, only on the VPN client side. > For the same reason as above. > The first 2 problems are only minor. Thanks to ARP, there will be a > broadcast sooner or later causing LAN nodes which have roamed between VPN > clients to be rediscovered. ARP is not always enough because a client may use unicast packets to probe the destination and that would just not be flooded. Maybe the server could send some kind of NULL Ethernet broadcast packet to refresh the various forwarding tables in the bridges? > > However, when a LAN node roams from a VPN client to the VPN server, the 3rd > problem causes it to become unreachable from all VPN clients. Because > there's no address learning on the TAP interface, the VPN server does not > update its address tables and keeps forwarding towards the LAN node's old > VPN client until that disconnects. > Right. > Are these differences to conventional Ethernet switches intentional (e.g. > for security reasons)? If not, I could probably provide patches to fix > them, at least for the 3rd problem. > OpenVPN was not thought to be used in this scenarios. Personally it looks like you are trying to solve a problem using OpenVPN, even though it is not the right tool. It sounds more like you are working on a mesh network where clients are free to roam between nodes. Even though these are interesting problems to work on, I am not sure OpenVPN is the right thing to hack to solve them. Solving these problems into OpenVPN would introduce too much complexity imho and "roaming" is just a pandora's box which, once opened, will introduce several other little problems going beyond what you have described. Anyway, this is just my opinion. May I ask you what is the actual use case? Cheers, -- Antonio Quartulli
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
