4

GOAL: Access internal network devices and browse web via the tunnel.

192.168.2.x = internal network
192.168.3.x = openvpn server
192.168.2.111 = openvpn server on internal network

[root@openvpn ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.3.2     *               255.255.255.255 UH    0      0        0 tun0
192.168.3.0     192.168.3.2     255.255.255.0   UG    0      0        0 tun0
192.168.2.0     *               255.255.255.0   U     0      0        0 eth0
link-local      *               255.255.0.0     U     1002   0        0 eth0
default         192.168.2.254   0.0.0.0         UG    0      0        0 eth0

and

[root@openvpn ~]# cat /etc/openvpn/server.conf
port 1194 #- port
proto udp #- protocol
dev tun
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
reneg-sec 0
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so /etc/pam.d/login #- Comment this line if you are using FreeRADIUS
#plugin /etc/openvpn/radiusplugin.so /etc/openvpn/radiusplugin.cnf #- Uncomment this line if you are using FreeRADIUS
client-cert-not-required
username-as-common-name
server 192.168.3.0 255.255.255.0
push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "route 192.168.2.0 255.255.255.0"
keepalive 5 30
comp-lzo
persist-key
persist-tun
status 1194.log
verb 3

and

client
dev tun
proto udp
remote 18.4.79.28 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ca ca.crt
auth-user-pass
comp-lzo
reneg-sec 0
verb 3

I can connect just fine and access the VPN box. However, I can not browse the web or access other local network devices.

I have IPTables off. Do I need IP table rules or is my routing off?

I need 192.168.3.0 to access 192.168.2.0 :)

EDIT: forgot to mention, I do have this set;

net.ipv4.conf.default.forwarding=1

EDIT:

I used this:

[root@openvpn ~]# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source <SERVERIP>
[root@openvpn ~]# iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT

I GET:

pinging 192.168.2.5
reply from 192.168.3.1 destination host unreachable

4 Answers 4

5

There are two things you'll need to check and potentially fix.

First, you need to ensure that IP forwarding is turned on in the kernel. IP forwarding allows the kernel to pass packets from one interface to another. You can check this with the below:

$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

If you see a 0 instead of a 1, then you need to enable IP forwarding. The easiest and most reliable way is to add the following line to /etc/sysctl.conf (or modify it if there is already an entry for net.ipv4.ip_forward):

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

And then run sysctl -p to reload the configuration from that file.

Next, you will need to configure IPtables to do Network Address Translation (NAT) on the packets coming from the VPN. Otherwise, when those packets g'et sent out eth0, any devices that receive the packets won't know how to talk back (they dont have a route back to 192.168.3.0/24 through the VPN server). There are two ways you can setup the NAT: Static NAT (SNAT) and Masquerade. SNAT is recommended when the IP address on the outbound interface (eth0 in your case) is not expected to change. Masquerade mode is designed for dynamic IP situations such as dial-up or other dynamically assigned address configurations (cable modems, DSL, etc.). Both are configured similarly, though.

For SNAT, you would add an IPtables rule along the lines of (note, I used 192.168.2.13 because I don't know the IP you have assigned to eth0; you would want to change that as is appropriate):

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.2.13

If the IP address on eth0 is not static and reliable, you would use Masquerade, which would look like:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
2

You do need a iptables rule for the VPN clients to access the network.

First make sure your system allow NAT:

# Setup sysctl to enable NAT.
echo "# Allowing nat translation for VPN clients.
net.ipv4.conf.default.forwarding=1
net.ipv4.ip_forward=1" > "/etc/sysctl.d/openvpn.conf"
# load new sysctl config.
command sysctl -p "/etc/sysctl.d/openvpn.conf" > '/dev/null'

Then install the NAT iptables rule for the VPN network:

CURRENT_IP_RANGE="192.168.2"
command iptables -t nat -C POSTROUTING -s "${CURRENT_IP_RANGE}.0/24" \
                      -o 'eth0' -j MASQUERADE 2>'/dev/null' \
    || command iptables -t nat -A POSTROUTING -s "${CURRENT_IP_RANGE}.0/24" \
                       -o 'eth0' -j MASQUERADE

These rules are an extract of openvpn-tools, presented in Install and setup OpenVPN on Debian, a OpenVPN management script and how-to i've written.

Make sure also to have a DNS server accessible from your VPN clients. A simple answer is OpenDNS (8.8.8.8). A more complex, but may-be better solution is to install Bind on the server (this is the solution used by openvpn-tools).

openvpn-tools may be of interest to you as it provide clients configuration exports for various systems and automatize the setup of new VPN networks.

EDIT for Openvpn 2.x server and 1.5 client

See: OpenVPN releases notes.

To get OpenVPN 2.0 to talk with the 1.5/1.6 versions, put this in the 1.x config file:

tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
key-method 2

For TLS usage, key-method 2 is now the default.

17
  • Tried your script, still no luck. Even setup a debian fresh install server
    – user206999
    Jan 28, 2014 at 0:50
  • did you follow my install guide ? i've used it 3 times already without problems.
    – Biapy
    Jan 28, 2014 at 1:01
  • also, did you use the --nat and --gateway options: command openvpn-tools --domain="domain.vpn" --gateway='y' --nat='y'
    – Biapy
    Jan 28, 2014 at 1:10
  • Yes, I used gateway and nat :(
    – user206999
    Jan 28, 2014 at 1:12
  • hum... did your client connect to the vpn correctly ? what does openvpn-tools -d domain.vpn --status print you ?
    – Biapy
    Jan 28, 2014 at 1:22
2

I'm not sure if you are using AWS, but please make sure that you disable destination/source checking on any AWS instance you may be using to run this.

Right click on the instance, mouse over to Network, then there should be an option there.

If this doesn't help you, hope it helps someone else.

2
  • 1
    somehow i found this answer, the openvpn must be setup like a nat docs.aws.amazon.com/AmazonVPC/latest/UserGuide/… ... thanks @lobi
    – Pykler
    Nov 23, 2015 at 3:38
  • THANK YOU! All the other answers I could find suggested using NAT on the OpenVPN server which is an ugly and unnecessary workaround. Mar 17, 2016 at 21:56
0

In your situation you should try to use standard routing instead of using NAT (between the internal network and the openvpn network). NAT should be your last option.

The "edge router" (probably your CPE) (bewteen your internal network and the rest of internet) needs to send the packets for the VPN nodes (in 192.168.3.0/24) to the Open server. You have to add a route like this in the edge-router/CPE :

# This is the Linux command, find the equivalent for your router:
ip route add 192.168.3.0/24 via 192.168.2.111

Now this router may be a combo FAI-provided xDSL-model+router so you may not be able to do this.

If you cannot do this (you cannot add routes on your router) and if your edge router thinks your internal nerwork is 192.168.0.0/16 (or at least contains 192.168.3.0/34) you can setup an ARP proxy in eth0 for the VPN nodes in the main network :

echo 1 > /proc/sys/net/ipv4/conf/$xx/proxy_arp

with x=eth0, x=tun0, x=all (I don't really know in which interface you should set this option).

This ideas is that your OpenVPN server will answer ARP requests on the eth0 netrwork for the nodes in the VPN. It will only work is your router thinks that 192.168.3.0/24 is in the internal network : othetrwise, it will not send an ARP requests on the internal network.

You must log in to answer this question.