OpenVPN: different subnets for physical and virtual LANs?
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
OpenVPN: different subnets for physical and virtual LANs?
I have set up OpenVPN server using a bridged configuration. My networking "powers" aren't that advanced, so I did this by following the openvpn tutorial for bridged servers. I have tested this with several clients connecting to my server from different locations and it works very nicely (including broadcasts).
My server's LAN IP address is 192.168.2.4, and my LAN's mask is 24. Clients connecting to my server get assigned IP address that also fall within that subnet (i.e., the 192.168.2.x pool contains both physical machines in my home and "virtual" hosts). This is what the OpenVPN walkthrough specifies:
Setting bridge-start parameter Value
Ethernet Interface eth eth0
Local IP Address ip 192.168.8.4
Local Netmask eth_netmask 255.255.255.0
Local Broadcast Address eth_broadcast 192.168.8.255
VPN client address pool 192.168.8.128 to 192.168.8.254
Virtual Bridge Interface br br0
Virtual TAP Interface tap tap0
The problem here is that if I set up my phone/laptop to connect to my VPN server, it will only work when my phone/laptop's physical IP is NOT inside 192.168.2.x (i.e., only when I'm NOT home), which I can understand.
I was wondering if it would be possible for the VPN to fall within a different subnet (such as 10.0.1.x). I would also like to do that without adding another physical NIC to my server, or changing my physical IP address. I would imagine this is possible, since that's how hamachi does it.
Yea you can run a routed VPN instead of a bridged VPN, however, I am not exactly clear as to why you want this behavior. If you are home inside your firewall why would you need to connect to your VPN, this would be the only time this is an issue, unless you are on another network with the same netmask as yours at home. Just a note if you are running windows clients, it is recommended to use a bridged VPn as it is more reliable in windows. But anyways basically you need to chae the networking settings from bridged to routed. start bu changing the device type from tap to tun you also won't need the bridge script anymore to configure your adapters. eh, I can't remember all the steps, let me post my config with all the comments, read trhough you should be able to figure it out, if not ask for some more help. I have only posted the relevant parts that require changing.
# "dev tun" will create a routed IP tunnel,
# "dev tap" will create an ethernet tunnel.
# Use "dev tap0" if you are ethernet bridging
# and have precreated a tap0 virtual interface
# and bridged it with your ethernet interface.
# If you want to control access policies
# over the VPN, you must create firewall
# rules for the the TUN/TAP interface.
# On non-Windows systems, you can give
# an explicit unit number, such as tun0.
# On Windows, use "dev-node" for this.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel if you
# have more than one. On XP SP2 or higher,
# you may need to selectively disable the
# Windows firewall for the TAP adapter.
# Non-Windows systems usually don't need this.
# Configure server mode and supply a VPN subnet
# for OpenVPN to draw client addresses from.
# The server will take 10.8.0.1 for itself,
# the rest will be made available to clients.
# Each client will be able to reach the server
# on 10.8.0.1. Comment this line out if you are
# ethernet bridging. See the man page for more info.
;server 10.8.0.0 255.255.255.0
# Maintain a record of client <-> virtual IP address
# associations in this file. If OpenVPN goes down or
# is restarted, reconnecting clients can be assigned
# the same virtual IP address from the pool that was
# previously assigned.
# Configure server mode for ethernet bridging.
# You must first use your OS's bridging capability
# to bridge the TAP interface with the ethernet
# NIC interface. Then you must manually set the
# IP/netmask on the bridge interface, here we
# assume 10.8.0.4/255.255.255.0. Finally we
# must set aside an IP range in this subnet
# (start=10.8.0.50 end=10.8.0.100) to allocate
# to connecting clients. Leave this line commented
# out unless you are ethernet bridging.
;server-bridge 192.168.100.12 255.255.255.0 10.8.0.50 10.8.0.100
# Configure server mode for ethernet bridging
# using a DHCP-proxy, where clients talk
# to the OpenVPN server-side DHCP server
# to receive their IP address allocation
# and DNS server addresses. You must first use
# your OS's bridging capability to bridge the TAP
# interface with the ethernet NIC interface.
# Note: this mode only works on clients (such as
# Windows), where the client-side TAP adapter is
# bound to a DHCP client.
# Push routes to the client to allow it
# to reach other private subnets behind
# the server. Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
push "route 192.168.168.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"
# To assign specific IP addresses to specific
# clients or if a connecting client has a private
# subnet behind it that should also have VPN access,
# use the subdirectory "ccd" for client-specific
# configuration files (see man page for more info).
# EXAMPLE: Suppose the client
# having the certificate common name "Thelonious"
# also has a small subnet behind his connecting
# machine, such as 192.168.40.128/255.255.255.248.
# First, uncomment out these lines:
;route 192.168.40.128 255.255.255.248
# Then create a file ccd/Thelonious with this line:
# iroute 192.168.40.128 255.255.255.248
# This will allow Thelonious' private subnet to
# access the VPN. This example will only work
# if you are routing, not bridging, i.e. you are
# using "dev tun" and "server" directives.
# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# or bridge the TUN/TAP interface to the internet
# in order for this to work properly).
;push "redirect-gateway def1 bypass-dhcp"
# Certain Windows-specific network settings
# can be pushed to clients, such as DNS
# or WINS server addresses. CAVEAT:
# The addresses below refer to the public
# DNS servers provided by opendns.com.
;push "dhcp-option DNS 22.214.171.124"
;push "dhcp-option DNS 126.96.36.199"
# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.