Please tolerate my terrible ASCII Art, as drawing diagrams helps me to avoid not understanding problems.
(Internet)---R1---(Switch1)---(200.200.200.200 (eth0) box 192.168.122.1/24 (eth1))---(Switch2)---*(many VM using this network)--.. (switch2 below)
(Many VM Using the network on Switch2)
|---( 192.168.122.2/24 (eth0) , VPN VM 10.8.0.2/16 (tun0) )
|---( 192.169.122.X1/24 (eth0) , HTTP VM 10.8.0.Y1/16 (tun0) )
|---( 192.169.122.X2/24 (eth0) , SMTP VM 10.8.0.Y2/16 (tun0) )
|---( 192.169.122.X3/24 (eth0) , SMB/NFS VM 10.8.0.Y3/16 (tun0) )
|---( 192.169.122.X4/24 (eth0) , DB VM 10.8.0.Y4/16 (tun0) )
|---( 192.169.122.X5/24 (eth0) , etc VM 10.8.0.Y5/16 (tun0) )
Does that describe your network? (Realize the "switch2" on the top line is the same hardware as used on the next block.)
But need access by example to intranet server (192.168.122.3), by default from openvpn canot access to server.
By example, access control:
10.8.0.2: deny to all ip adress, access only to intranet (192.168.122.3)
10.8.0.3: deny to all ip adress, access only to intranet and database server (sysadmin) (192.168.122.3 and 192.168.122.4)
10.8.0.4: (is a seller) deny to all ip adress, access only to storage server, intranet, jira, etc
10.8.0.5: (is a sysadmin) access to all 10.8.x.x and 192.168.122.x ranges.
Etc...
Ok.
What is the best practice for make this?:
1. Setting iptables to bridge, all tun0 interface connections to eth0 and manage access from iptables (access and drop)?
2. Install openvpn client in all servers and connect all servers to openvpn server and set 10.8.x.x ip adress for each server?
3. Unknown other options?
I do not know there is a "best" way, but let me propose some for consideration:
Break the problem into smaller parts. The first part is "How to members of the VPN talk to each other, or not talk to each other and what can be done to provide for this?"
Distribute the access control to each host. Each host should decide who is allowed to talk to it and on which ports, whether on the VPN with a tun interface or out their LAN/eth* interfaces.
As for Internet access, control that from "200.200.200.200" (assuming members of 192.168.122.0/24 talk through it to get to the Internet, and not through a tun with the VPN VM doing NAT for them.)
On the VPN hub, allow all clients to talk to all other clients. Enable OpenVPN option "client-to-client" and either go wither full bridging (layer2), or IP forwarding being enabled, making the VPN VM into a router (layer3).
Now, each host is responsible for who can say what to where, and how will VPN client be able to specify who can talk to them without knowing each "who" by IP address?
For this part, consider openvpn config item "ifconfig-pool-persist FILENAME". It kind of like a "dhcp.leases" file mapping "Common Name" with "IP Address". If each client has a unique CN, and no re-use is allowed, and you pre-populate this file with all possible "CN" (common name) then each host should re-use the same IP each time it connects. (So, do NOT enable "duplicate-cn" and give each client their own cert/CN.) You can then distribute this list of IP to each host to add to their own network filters, or run a DNS internally that converts names to IP for filter scripts to read and use.
These hosts on 192.168.122.0/24 will already have to have network rules for which services network members of 192.168.122.0/24 will be allowed to connect to. Why not also have rules for their tun?
With all of these in place, you could also enable rules on the VPN VM, but it would quickly get messy, complicated with a high risk for failure by accident. It is possible to contain all network filtering in the VPN VM with different rules for each client, but not advised.
Does openvpn always depend on iptables or another firewall? Is it possible to do all this only through the openvpn service?
I've tried doing all this with iptables but it's complicated and it does not work well for me.
OpenVPN's primary job is to "create a connection between two systems across a hostile network." Enabling support for crypto and bi-directional validation and encryption improves this to the job of "creating a 'secure' connection between two trusted hosts across a hostile network." Though it does do some things to make many common uses easier (routing advantages for example, some DoS protections) it is not meant to be a full OS with support for all things. To get access control for unique-per-client network restrictions on a single VPN instance, you will need more tools from the OS than just features in OpenVPN.
