OpenVPN Server Config to Allow Road Warriors Access to LAN

mozart

Hi everyone,

I have read tons of articles and documentation I am still unable to figure out the solution for my needs. If someone could help me I would be very grateful.

I am running OpenVPN server on Ubuntu server. My clients are connecting with Tunnelblick on Mac OS X.

I have an OpenVPN server operating on my LAN and it is not the gateway. It is simply a server that resides on our LAN. It is behind a Cisco 2801 which I have NATed to allow requests to the public IP to forward to the private IP of my OpenVPN server (192.168.1.250). The rest of my LAN operates on IP addresses in the 192.168.1.X range.

I have configured my OpenVPN server to provide the IP range of 192.168.1.200 to 192.168.1.215 to OpenVPN clients.

I am able to connect. However, as seems to often be the problem with other people's installs, when the client is on a remote network that also assigns 192.168.1.X addresses, I am not able to access the resources behind the OpenVPN server on my LAN because there is no way to differentiate between the 192.168.1.X address of the LAN and the 192.168.1.X address provided to the client on the remote side.

Can someone help me with a solution that does not include changing the IP scheme of my LAN (not possible)?

Additionally, and this is a specific OS X question: My LAN has many Macs that share their folders so that users can exchange files between them. I am unable to access this feature if connected to the VPN. Can someone also help me with this? I need for someone on the LAN to be able to drop a file on a Road Warrior's Mac when they are connected over the VPN, and vice-versa.

Below are some of my config. Please let me know if there is anything else that I can provide to help you with my setup. Thanks in advance for the help!

I am using a single ethernet port configured as a bridge:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto br0
iface br0 inet static
address 192.168.1.250
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
bridge_ports eth0
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp off

Some information from my server.conf file:

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 1194

# TCP or UDP server?
;proto tcp
proto udp

# "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.
dev tap0
up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"

# 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.1.250 255.255.255.0 192.168.1.200 192.168.1.215

# 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.1.1 255.255.255.0"
push "dhcp-option DNS X.X.X.X" [color=#FF0000]DNS SERVERS DELETED FOR PRIVACY[/color]
push "dhcp-option DNS X.X.X.X" [color=#FF0000]DNS SERVERS DELETED FOR PRIVACY[/color]

And on the client side:

# Specify that we are a client and that we
# will be pulling certain config file directives
# from the server.
client

# Use the same setting as you are using on
# the server.
# On most systems, the VPN will not function
# unless you partially or fully disable
# the firewall for the TUN/TAP interface.
dev tap
;dev tun

# Windows needs the TAP-Win32 adapter name
# from the Network Connections panel
# if you have more than one.  On XP SP2,
# you may need to disable the firewall
# for the TAP adapter.
;dev-node MyTap

# Are we connecting to a TCP or
# UDP server?  Use the same setting as
# on the server.
;proto tcp
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote <PUBLIC ADDRESS OF OPENVPN SERVER> 1194
;remote my-server-2 1194

Again, thanks very much for your help. I am very new to OpenVPN and am very happy with it. I just need to make it work for us!

george

I would switch to a routed setup rather than using a bridged setup, here's the howto:

http://openvpn.net/index.php/open-source/documentation/howto.html#vpntype

I am able to connect. However, as seems to often be the problem with other people's installs, when the client is on a remote network that also assigns 192.168.1.X addresses, I am not able to access the resources behind the OpenVPN server on my LAN because there is no way to differentiate between the 192.168.1.X address of the LAN and the 192.168.1.X address provided to the client on the remote side.

The problem is that routing won't know where to push traffic to, you need to change your VPN setup to a routed setup, and use something like 10.8.0.0/24 subnet, as refered to in the routed setup howto I mentioned earlier.

mozart

Thank you very much for the reply. I will read through your link.

mozart

So after a quick read-through it is my understanding that routing is actually not the ideal solution? Wouldn't changing to a routed setup restrict the use of Bonjour? Since my VPN clients need access to Bonjour to get to shared resources on my LAN that would not be ideal.

mozart

Ah! Got the Bonjour issue fixed. It was a silly thing that I was doing. The user simply needed to log in to the shared resource under the correct credentials and save that info in their keychain. :oops: It was defaulting to use the current connected user's log-in info.

Still need help on the issue of local IPs. I am headed off to re-read Mimiko's draft how-to on this issue.

george

I can't speak to bonjour issues with OpenVPN, we use samba and native windows shares in my environment rather than users wirting/reading files from other user's machines so the data is easily backed up.

mozart

I've posted additional information in Mimiko's Tutorial thread here: https://forums.openvpn.net/topic9465.html

Can anyone else help me? I'd really like to have this running properly this week.