Expanding the Scope of Your VPN: Connecting More Machines for Seamless Access

Published Categorized as Guide

In the realm of Virtual Private Networks (VPNs), the ability to connect various machines seamlessly can be a game-changer. Whether you’re on the server side or the client side, extending the reach of your VPN beyond a single machine opens up new possibilities. Let’s dive into the nitty-gritty of including multiple machines on either the client or server subnet.

Including Multiple Machines on the Server Side with Routed VPN (dev tun)

So, your VPN is up and running smoothly in a point-to-point setup between your client and server. Now, what if you want clients to access not just the server but multiple machines on the server network? Here’s how you can achieve that:

Advertising the Server-Side Subnet

In your server-side config file, add the following directive:

push "route 10.66.0.0 255.255.255.0"

This advertises the server-side subnet (10.66.0.0/24) to VPN clients.

Setting Up Routes on the Server-Side LAN Gateway

If your OpenVPN server and LAN gateway are different machines, ensure you’ve enabled IP and TUN/TAP forwarding on the OpenVPN server.

Including Multiple Machines on the Server Side with Bridged VPN (dev tap)

The beauty of ethernet bridging is that you get this benefit without any additional configuration.

Including Multiple Machines on the Client Side with Routed VPN (dev tun)

In scenarios where the client machine is a gateway for a local LAN, enabling each machine on the client LAN to route through the VPN is the goal. Follow these steps:

Basic Prerequisites

  • Ensure the client LAN subnet is unique.
  • The client must have a unique Common Name in its certificate.
  • Enable IP and TUN/TAP forwarding on the client machine.

Server-Side Configuration Changes

Add a client configuration directory to the server configuration file:

client-config-dir ccd

Create a file in the directory (e.g., client2) with the line:

iroute 192.168.4.0 255.255.255.0

Also, add the following to the main server config file:

route 192.168.4.0 255.255.255.0 client-to-client push "route 192.168.4.0 255.255.255.0"

Including Multiple Machines on the Client Side with Bridged VPN (dev tap)

This setup is more intricate, requiring a bridged TAP interface and manual IP/netmask configuration on the client.

FAQs

  1. Is it necessary to enable IP and TUN/TAP forwarding on both the client and server machines?
    • Yes, enabling IP and TUN/TAP forwarding is crucial for the proper functioning of the VPN, especially when including multiple machines.
  2. Why are redundant route and iroute statements needed in the server-side configuration?
    • Both route and iroute statements serve distinct purposes in controlling routing, addressing both the kernel-to-server and server-to-client communication.
  3. What precautions should be taken when dealing with client LAN subnets in a routed VPN scenario?
    • Ensuring uniqueness of client LAN subnets and having distinct Common Names in certificates are fundamental prerequisites to avoid conflicts.