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.
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. 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. 3. On the VPN server, there's no (source) address learning on the TAP interface, only on the VPN client side. 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. 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. 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. Thanks, 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
