[Discussion continues on openvpn-devel, see my response to Gert's message in this thread]
Hi Antonio, sorry for the late reply, real life currently causes lots of interrupts... On Tue, Nov 28, 2017 at 10:11:57PM +0800, Antonio Quartulli wrote: > > 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'? No, there's just one OpenVPN server or client per LAN segment plus several non-OpenVPN nodes. > To be honest, I think I can safely claim that OpenVPN is not designed > for this kind of scenario. Even if we limit this to one OpenVPN client/server per LAN? Why? What is the intended use case for OpenVPN's bridged mode then? > > 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. Well, an attacker can do this trivially today using broadcast/multicast, so I don't see a new problem here. But using rate-limits for flooding might be a good idea in any case. > > 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. Then it probably shouldn't be called "bridged mode", because that's a pretty fundamental feature of an Ethernet bridge. > ARP is not always enough because a client may use unicast packets to > probe the destination and that would just not be flooded. If those unicast probes fail, the ARP implementations I know usually fall back to broadcast, it just needs a bit more time. And I'm not suggesting that we *should* rely on ARP to get us out of the trouble, it just happens to achieve this today in typical situations (unless you roam towards the OpenVPN server in which case you're simply out of luck). So issues 1/2 I listed are not as critical as 3. > Maybe the server could send some kind of NULL Ethernet broadcast packet > to refresh the various forwarding tables in the bridges? It's not the bridges which have problems, it's the server itself. Sure, one could speed up roaming by sending learning frames, but I'd prefer to make it work at all first before trying to optimize it. > 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. If this were a localized network, I'd agree. But we need some kind of VPN anyway since the networks we typically use involve a hop via LTE or some other untrusted networks. So we'd have to tunnel a Mesh network through OpenVPN. Possible, but not very useful because we don't need the multi-hop features of typical Mesh networks as OpenVPN already provides a simple star topology. Or we could use Ethernet encapsulated in GRE and route that through an L3 OpenVPN. In this case, the bridges connected to the GRE tunnel endpoints would handle the dynamic topology. That would most likely work, but why add the GRE/IP overhead when OpenVPN already knows how to bridge Ethernet? > 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. I'm not 100% convinced ;-) As far as I understand, OpenVPN already implements most of the basic mechanisms required to make such a scenario work (MAC address learning+expiration, flooding), they just would have to be used/enabled properly in such a case. One could even make the flooding part configurable so you'd be able to keep the "safe, but only works for static topologies" properties of today's implementation. > Anyway, this is just my opinion. May I ask you what is the actual use case? When I encountered these problems the first time, the use case was "connection of legacy networks via LTE". These legacy networks are typically inside vehicles, so they move around. Not every vehicle has got its own LTE connection, so they may connect to nerby vehicles which do using WiFi or by manually running fiber optic cables. And this ultimately means that a vehicle and all the nodes connected to its LAN may appear behind different VPN clients over time. Martin ------------------------------------------------------------------------------ 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
