When establishing OpenVPN connections between Windows servers and Linux clients, a common roadblock emerges: the inability to access the client's local network (192.168.1.0/24) from the server side, despite successful VPN peer communication (10.10.0.0 network). This occurs because OpenVPN doesn't automatically create routes to client-side networks.

The complete solution requires three synchronized configurations:

# Server configuration (server.ovpn)
client-config-dir ccd
route 192.168.1.0 255.255.255.0
push "route 172.16.1.0 255.255.255.0"

Client-specific configuration in ccd/client file:

iroute 192.168.1.0 255.255.255.0
ifconfig-push 10.10.0.2 10.10.0.1

Persistent route addition on Windows Server:

route -p add 192.168.1.0 MASK 255.255.255.0 10.10.0.2
netsh interface ipv4 add route 192.168.1.0/24 "OpenVPN Interface" 10.10.0.2

On the Debian client, enable IP forwarding and NAT:

echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -o eth0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT

To avoid manual route configuration on each client device, implement these solutions:

Option 1: DHCP scope modification

# DHCP server configuration example
subnet 192.168.1.0 netmask 255.255.255.0 {
    option routers 192.168.1.5;
    option classless-static-routes 10.10.0.0 255.255.255.0 192.168.1.5;
}

Option 2: RADVD for IPv6 environments

interface eth0 {
    AdvSendAdvert on;
    prefix 2001:db8:1::/64 {
        AdvOnLink on;
        AdvAutonomous on;
    };
    route 10.10.0.0/24;
};

Diagnostic commands to verify configuration:

# On Windows server
tracert -d 192.168.1.10
route print -4

# On Linux client
tcpdump -i tun0 icmp
ip route show table all

When establishing an OpenVPN tunnel between Windows Server 2012 and Debian Linux, we often encounter a common routing challenge: while VPN peers can communicate directly (10.10.0.1 ↔ 10.10.0.2), accessing the client's entire local network (192.168.1.0/24) from the server remains problematic. This occurs because OpenVPN doesn't automatically configure routing for networks behind connected clients.

To enable proper routing between the server and client's LAN network, we need to implement three critical configurations:

# Server configuration (server.ovpn)
client-config-dir ccd
route 192.168.1.0 255.255.255.0
push "route 192.168.1.0 255.255.255.0"

The client-config-dir directive points to a directory containing client-specific configurations. Create this directory in your OpenVPN config folder.

Inside the ccd directory, create a file named exactly as your client's Common Name (CN) in the certificate. For a client named "debian-client":

# ccd/debian-client
iroute 192.168.1.0 255.255.255.0
ifconfig-push 10.10.0.2 10.10.0.1

The iroute (internal route) directive tells OpenVPN about networks behind this specific client.

For the Debian client to properly route traffic between networks:

# On Debian client
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT

On the Windows Server, execute these commands in an elevated command prompt:

route add 192.168.1.0 mask 255.255.255.0 10.10.0.2
netsh interface ipv4 set interface "TAP-Windows Adapter V9" forwarding=enabled

To avoid manual route additions on each LAN client, configure the Debian machine as a gateway:

# On Debian client
sysctl -w net.ipv4.conf.all.forwarding=1
sysctl -w net.ipv4.conf.default.forwarding=1

# Persistent configuration
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf

After implementing these changes:

1. Restart OpenVPN services on both ends
2. Verify routes with route print (Windows) or ip route (Linux)
3. Test connectivity with tracert 192.168.1.5 (Windows) or traceroute 10.10.0.1 (Linux)