I’ve got a really weird request, is it possible to setup a TAP VPN concentrator that allows a single user VPN to connect to multiple TAP-enabled remote VPN’s? The use case is enabling a user to have a SINGLE vpn connection to a server, and have access to multiple remote sites (not at the same time, one at a time). Does that make sense?
I mean you could but why make it a TAP network? It would be a nightmare to avoid IP collisions and also it would be vulnerable to broadcast bombs.
It sounds like you want to build a remote service VPN. If that’s the case, what I do is to have all the clients connect to a central VPN server in TUN mode and block all routing between clients, then each client has an openvpn server running on it that the operator can connect to. That way you can connect to any installations site while keeping them isolated from each other.
It must be a TAP network so the user can use broadcasting to find specific devices on the far end.
I need that too, that’s why the second VPN I use to connect with the remote end is TAP. But the first VPN, the one that connects all the installation sites to my central VPN, doesn’t have to be.
This is interesting, are you saying the user uses a TUN vpn to connect to a central VPN server, and from there it uses TAP to the remote site? Can you describe this a little more? It seems that using TUN from the server to the user would prevent broadcasts from reaching the remote site (even though there is a TAP vpn from the server to the remote site)?
Yes. In order to do this every peer (remote sites and users) must have at least two virtual adapters and two configuration files.
The first is a “standard” TUN VPN where everyone is a client connecting to some central server you own. This way only the central openvpn server needs to be open to the internet, while everyone else can safely operate behind firewalls/NATs/proxy, for improved security. For this VPN i use the 172.64.0.0/16 subnet which is designed as private network range but very seldom used, and I assign static IPs using an ifconfig-pool-persist file on the server. Furthermore, I disable client-to-client in the server configuration file and configure iptables to only allow routing between users and remote sites, so that the remote sites cannot communicate with each other.
Once you have everyone connected to the same VPN you can just have the users connect to the remote sites with a TAP VPN as they need, which will support broadcasting. To do this you need to configure a server on each remote site, and a client file on the users to connect to the server. Actually on my laptop I have a config file for each installation site (I work in the industrial automation industry), so I can just choose the one I want to connect to using the openvpn gui menu.
Now you just have to tell your users to connect to the central VPN and then connect to the remote site they need to service. This approach has the very useful perk of making each remote site completely independent from each other, so that you can re-use the same ip addresses and subnets every time, which helps a lot with servicing similar installation sites. Let’s say I did a PLC program change that must be deployed both to site A and B, which PLC both have the same local IP. I can connect to installation site A, go online with the PLC and do my job, then I disconnect from site A and connect to site B and go online again using the same project, IP included, and just deploy again.
Thank you for the detailed reply. My hope was that I could have users use a SINGLE vpn tunnel on their laptop to a centralized server, and use some sort of web interface on that server where the user can login, and choose which remote site they want to connect to (using TAP). This way, they do not need to maintain all kinds of different TAP config files on their laptop. Does that make sense?
I see. Well then you can use iptables rules on the central server to do that quite easily, just make scripts to build forwarding rules (AKA destination NAT) so that the traffic from one user VPN IP gets forwarded to the remote site VPN IP they authenticated for.