Isolate network segments in OpenVPN by assigning unique virtual subnets to client groups and enforcing strict server-side firewall rules. This approach prevents cross-subnet traffic, ensuring that Group A cannot reach Group B resources while both maintain secure access to shared services through carefully configured iptables or nftables policies.
Network Architecture Design
Before configuring the software, you must define the logical topology. Each group of users requires a distinct virtual subnet within the VPN tunnel. For example, assign10.8.1.0/24 to the Engineering team and 10.8.2.0/24 to the Marketing team. The OpenVPN server itself should reside on a separate management subnet, such as 10.8.0.0/24, to avoid routing conflicts.
This separation is critical because OpenVPN does not automatically isolate traffic between clients connected to the same server instance. By default, if multiple clients connect, they can often see each other unless explicitly blocked at the network layer. You must plan your IP address allocation to ensure no overlap with your physical LAN subnets. If your internal network uses 192.168.1.0/24, do not use any addresses from that range for your VPN pools. This prevents ambiguous routing decisions where the server might attempt to send VPN traffic out through the local gateway instead of the tunnel interface.
OpenVPN Server Configuration
The core configuration file, typically located at/etc/openvpn/server.conf (Linux) or your designated config directory (Windows), must be modified to support multiple subnets. You cannot simply push a single route for all clients; you need a mechanism to differentiate them. The most robust method involves using certificate-based identification or username/password authentication combined with specific configuration blocks.
First, ensure your server listens on the correct port and protocol. Then, define the virtual network. Instead of a single server directive, you may need to run multiple instances of OpenVPN, each bound to a different local IP or using a different port, or configure a single instance with advanced routing features. For simplicity and clarity, we will assume two separate server instances or profiles for this guide, which is a common pattern for strict isolation.
Create a configuration file for Group A (groupA.conf):
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
# Virtual network for Group A
server 10.8.1.0 255.255.255.0
# Do NOT allow direct client-to-client communication
client-to-client no
# Push routes for internal resources accessible by Group A
push "route 192.168.10.0 255.255.255.0"
groupB.conf) with the subnet 10.8.2.0. Crucially, set client-to-client no in both files. This directive disables Layer 2 bridging between clients, forcing all traffic through the server. However, note that client-to-client no only prevents direct peer-to-peer communication; it does not prevent clients from reaching each other via routed packets if the server's kernel allows forwarding. Therefore, firewall rules are mandatory.
For Windows environments, these configurations are managed through the service properties or the EasyRSA-generated scripts, ensuring each profile points to its respective config file. Remember to restart the OpenVPN service after every change.
Server-Side Firewall Rules
This is the most frequently overlooked step. Even withclient-to-client no, the Linux kernel may forward packets between interfaces if IP forwarding is enabled. You must implement explicit deny rules for inter-subnet traffic. Using iptables as an example, add rules to your chain before any accept rules.
Assuming tun0 is the interface for Group A and tun1 for Group B:
# Drop traffic between Group A and Group B
iptables -I FORWARD -i tun0 -o tun1 -j DROP
iptables -I FORWARD -i tun1 -o tun0 -j DROP
# Allow traffic from VPNs to the internet or local LAN (if needed)
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i tun1 -o eth0 -j ACCEPT
nftables or advanced iptables mangle tables to match source IPs. For instance, drop any packet originating from 10.8.1.0/24 destined for 10.8.2.0/24. This ensures that even if routing tables are misconfigured, the firewall acts as the final gatekeeper. On Windows, use the built-in Windows Firewall with Advanced Security to create inbound and outbound rules blocking traffic between the specific VPN adapter IP ranges.
Without these rules, a user in Group A could potentially ping or SSH into a device in Group B, violating your security isolation requirements. Always test these rules with iptables -L -v -n to verify their order and hit counts.
Client Configuration and Routing
Clients must know how to reach their own subnet and any shared resources. In the client configuration file (client.conf), include the necessary push directives or static routes. For Group A, the client config should look like this:
client
dev tun
proto udp
remote your-server-ip 1194
resolv-retry infinite
nobind
ca ca.crt
cert client_A.crt
key client_A.key
# Ensure the client uses the VPN for specified networks
redirect-gateway def1 bypass-dns
The redirect-gateway def1 directive forces all traffic through the VPN. If you want to restrict traffic only to specific internal subnets, remove this line and manually add route statements for each target network. For example:
route 192.168.10.0 255.255.255.0
route 10.8.1.0 255.255.255.0
This tells the client OS to send packets for 192.168.10.0/24 and 10.8.1.0/24 through the VPN tunnel. It is vital that clients do not have routes for other VPN subnets (like 10.8.2.0/24) unless those routes are explicitly allowed by the server firewall. If a client accidentally receives a route for another group's subnet, it will attempt to send traffic there, which will then be dropped by the server firewall, resulting in silent failures that are difficult to debug.
Diagnostics and Troubleshooting
When connectivity issues arise, first check the OpenVPN logs on the server. Look for errors related to certificate validation or key mismatches. Next, verify that the firewall rules are active. Run iptables-save and confirm that the DROP rules for inter-subnet traffic are present and positioned correctly. Use tcpdump on the server interfaces to inspect packet flow. If you see packets arriving on tun0 but not leaving towards the destination, the firewall is likely blocking them, which is the desired behavior. If packets are being forwarded incorrectly, review your kernel routing table with ip route show.
For persistent issues, ensure that SELinux or AppArmor profiles are not interfering with OpenVPN operations. On Linux, check /var/log/syslog or /var/log/messages for denials. On Windows, check the Event Viewer under Application and Service Logs > OpenVPN.
Related articles:
Make cURL establish TLS connection with CA unknown helps troubleshoot certificate issues that might prevent clients from connecting securely to the OpenVPN server.
Self-Host Website via External Router provides context on managing external access, which is relevant when configuring port forwarding for your VPN server.
Frequently Asked Questions
Can I use a single OpenVPN instance for all subnets?
Yes, but it requires advanced policy routing on the server side. You must assign different source IPs to different certificates and use iptables or nftables to route them to different virtual interfaces or apply different NAT rules. This is significantly more complex than running separate instances and is prone to misconfiguration.
Why do my clients still see each other despite client-to-client no?
Because client-to-client no only disables Layer 2 bridging. If IP forwarding is enabled in the kernel, the server can still route packets between clients if the firewall allows it. You must explicitly add DROP rules to the firewall chain to block inter-client traffic.
How do I handle DNS resolution for isolated groups?
You should run a local DNS resolver or use the server's DNS settings. Push the DNS server option to clients so they resolve internal hostnames correctly. Ensure that the DNS server is accessible from all subnets, or provide separate DNS servers for each group if name resolution needs to be segmented.
What happens if I forget to add firewall rules?
Clients will be able to communicate directly with each other through the server, effectively breaking the isolation model. This creates a security risk where unauthorized users in one group could access resources belonging to another group. Always verify firewall rules immediately after deployment.
Can I migrate existing clients to new subnets easily?
Yes, but you must update the client configuration files to reflect the new subnet routes. Clients will need to reconnect to receive updated routing information. Ensure that the old subnet is decommissioned gradually to avoid downtime during the transition period.