User Tools

Site Tools


doc:howto:vpn.openvpn
This wiki is read only and for archival purposes only. >>>>>>>>>> Please use the new OpenWrt wiki at https://openwrt.org/ <<<<<<<<<<

This is an old revision of the document!


OpenVPN Setup Guide for Beginners

This is a beginner's guide to setting up OpenVPN on a server and a client where, in this instance, both are running OpenWrt (although the OpenVPN client could easily be running on another OS, such as Windows or Linux).

For non-beginners or real-world tunnels, vpn.server.openvpn.tun may be a better place to start.

The primary goal of this HOWTO is to get a working OpenVPN tunnel; the strategy used by this HOWTO is to keep it simple. Because of that, this is a very basic OpenVPN tunnel configuration that will not suit most people's needs without further configuration. However, once the basic tunnel is working, additional recipes for other use-cases can be found at vpn.server.openvpn.tun.

For an overview of all VPN-related articles (including other VPN technologies), see vpn.overview.

Use Case (the beginner's configuration)

The user wants a client to access their OpenWrt router without the possibility of being snooped. That is, the user can already access the router, but over a public network, such as the Internet. The end result will be a private connection directly between the OpenVPN client and server. Mostly, it is as if the two end-points are on the same subnet (but not on the same subnet as your router's LAN).

This HOWTO offers instructions on three OpenVPN distinct configurations:

  • Default (TUN) Server: The simplest type of OpenVPN server to configure, clients are exclusively managed by OpenVPN and can be assigned IP addresses by the OpenVPN server under their own distinct subnet.
  • Server-Bridge (TAP) Server: Also called an ethernet-bridge, this configuration creates a virtual ethernet cable between the server and client. This means that clients will be treated by the router as if they were plugged into it like any other computer. They will be assigned an IP address by the network's DHCP server (most commonly the router itself).
  • Client: OpenVPN will act as a client and connect to a remote server.

It should be noted that using a TAP adapter is not a synonym for server-bridging, however a TAP adapter is required for server-bridging, whereas TUN is almost always superior if not bridging. For the sake of simplicity, we will use these terms interchangeably, since comparing the terms "server" and "server-bridge" could cause confusion. TUN will be used to refer to a traditional server and TAP will refer to a server-bridge configuration.

While it is possible to configure OpenVPN on OpenWRT using a remote connection (through SSH, for example), it is recommended that testing is performed locally with the Default (TUN) Server, as this will simplify any troubleshooting. If using a TAP server, it is better to test with a remote connection if possible since a server-bridge connection will use the same subnet and your client will be assigned two IP addresses on the same network (which may or may not cause connectivity issues).

A TUN server has less overhead, and will only send traffic destined for the client, where a TAP server is less efficient and will send broadcast packets to the clients.

A TUN server can use the same subnet as the local network's DHCP server if desired, but it should assign addresses outside of the DHCP server's range, or IP conflicts may occur (two clients assigned the same IP, one by DHCP and the other by OpenVPN).

A TUN server is easier to set up security for, since clients can be on a separate subnet that is easily firewalled. Since these clients are not sent broadcast data, a malicious client would be able to access less data on the network.

A TAP server integrates clients into the network in a more seamless manner, and can simplify the process for setting up a variety of network applications. However, such integration may come at the price of security. Please note that regardless of method chosen, setting up proper firewall rules is essential for proper security, and is far more important than the discrimination between TUN and TAP servers.

:!: If using a TAP server, it is highly recommended that you change your DHCP subnet to something other than 192.168.0.XXX or 192.168.1.XXX. These are very common and will cause routing conflicts and connectivity issues if you attempt to connect from a client attached to a router utilizing the same subnet. This can generally be accomplished by changing the IP address of the OpenWRT/OpenVPN router to something like 192.168.7.1

Prerequisites

This HOWTO requires that the OpenVPN server is an OpenWrt router running OpenWrt 15.05 Chaos Calmer.

Install the required software

opkg update
opkg install openvpn-openssl openvpn-easy-rsa

Create the certificates

If you are creating an OpenVPN server (either type), you must create security certificates using the instructions below. If you are using OpenVPN as a client, the required certificates should have been provided with your configuration details.

build-ca
build-dh
build-key-server my-server
build-key-pkcs12 my-client

The above creates a server certificate named my-server and a client certificate named my-client. You can create multiple client certificates by running build-key-pkcs12 multiple times and specifying different names.

You can create a new set of certificates by running clean-all and then the above commands again.ls

Distribute the certificates

Copy your server keys to the /etc/openvpn directory so that they don't get overwritten.

cp /etc/easy-rsa/keys/ca.crt /etc/easy-rsa/keys/my-server.* /etc/easy-rsa/keys/dh2048.pem /etc/openvpn
Copy the client keys to your SSH machine so you can distribute it to your intended client. This is just a reference for ease of use - these keys can be distributed in whatever way is most convenient (i.e. USB drive).
scp /etc/easy-rsa/keys/ca.crt /etc/easy-rsa/keys/my-client.* root@CLIENT_IP_ADDRESS:/etc/openvpn

Configure the network on the OpenWrt router

Traditional (TUN) Server

  1. Create the VPN interface:
    uci set network.vpn0=interface
    uci set network.vpn0.ifname=tun0
    uci set network.vpn0.proto=none
    uci set network.vpn0.auto=1
  2. Allow incoming client connections:
    uci set firewall.Allow-OpenVPN-Inbound=rule
    uci set firewall.Allow-OpenVPN-Inbound.target=ACCEPT
    uci set firewall.Allow-OpenVPN-Inbound.src=*
    uci set firewall.Allow-OpenVPN-Inbound.proto=udp
    uci set firewall.Allow-OpenVPN-Inbound.dest_port=1194
  3. Create firewall zone for new vpn0 network. By default, it will allow both incoming and outgoing connections being created within the VPN tunnel. Edit the defaults as required. This does not (yet) allow clients to access the LAN or WAN networks, but may allow connections between VPN clients if your OpenVPN server configuration allows:
    uci set firewall.vpn=zone
    uci set firewall.vpn.network=vpn0
    uci set firewall.vpn.input=ACCEPT
    uci set firewall.vpn.forward=REJECT
    uci set firewall.vpn.output=ACCEPT
    uci set firewall.vpn.masq=1
  4. If you plan to allow clients to connect to computers within your LAN, you'll need to allow traffic to be forwarded between the vpn firewall zone and the lan firewall zone:
    uci set firewall.vpn_forwarding_lan_in=forwarding
    uci set firewall.vpn_forwarding_lan_in.src=vpn
    uci set firewall.vpn_forwarding_lan_in.dest=lan
    And you'll probably want to allow your LAN computers to be able to initiate connections with the clients, too.
    uci set firewall.vpn_forwarding_lan_out=forwarding
    uci set firewall.vpn_forwarding_lan_out.src=lan
    uci set firewall.vpn_forwarding_lan_out.dest=vpn
  5. Similarly, if you plan to allow clients to connect the internet (WAN) through the tunnel, you must allow traffic to be forwarded between the vpn firewall zone and the wan firewall zone:
    uci set firewall.vpn_forwarding_wan=forwarding
    uci set firewall.vpn_forwarding_wan.src=vpn
    uci set firewall.vpn_forwarding_wan.dest=wan
  6. Commit the changes:
    uci commit network
    /etc/init.d/network reload
    uci commit firewall
    /etc/init.d/firewall reload

Server-Bridge (TAP) Server

  1. Create the VPN interface:
    uci set network.vpn0=interface
    uci set network.vpn0.ifname=tap0
    uci set network.vpn0.proto=none
    uci set network.vpn0.auto=1
  2. Add interface to LAN bridge:
    uci set network.lan.ifname="$(uci get network.lan.ifname) tap0"
  3. Allow incoming client connections:
    uci set firewall.Allow-OpenVPN-Inbound=rule
    uci set firewall.Allow-OpenVPN-Inbound.target=ACCEPT
    uci set firewall.Allow-OpenVPN-Inbound.src=*
    uci set firewall.Allow-OpenVPN-Inbound.proto=udp
    uci set firewall.Allow-OpenVPN-Inbound.dest_port=1194
  4. Commit the changes:
    uci commit network
    /etc/init.d/network reload
    uci commit firewall
    /etc/init.d/firewall reload

Client

  1. Create the VPN interface:
    uci set network.vpn0=interface
    uci set network.vpn0.ifname=tun0
    uci set network.vpn0.proto=none
    uci set network.vpn0.auto=1
  2. Create firewall zone for new vpn0 network. By default, it will allow both incoming and outgoing connections being created within the VPN tunnel. Edit the defaults as required. This does not (yet) allow clients to access the LAN or WAN networks, but may allow connections between VPN clients if your OpenVPN server configuration allows. :!: If you are planning to use your OpenVPN client as a second (or replacement) WAN adapter, it's recommended that you reject incoming traffic by default:
    uci set firewall.vpn=zone
    uci set firewall.vpn.network=vpn0
    uci set firewall.vpn.input=ACCEPT #REJECT if using as WAN replacement
    uci set firewall.vpn.forward=REJECT
    uci set firewall.vpn.output=ACCEPT
    uci set firewall.vpn.masq=1
  3. If you plan to allow clients behind the VPN sesrver to connect to computers within your LAN, you'll need to allow traffic to be forwarded between the vpn firewall zone and the lan firewall zone:
    uci set firewall.vpn_forwarding_lan_in=forwarding
    uci set firewall.vpn_forwarding_lan_in.src=vpn
    uci set firewall.vpn_forwarding_lan_in.dest=lan
    And if you want to initiate connections to clients (or the internet) behind the VPN server, you want to allow your LAN computers to be able to initiate connections with them.
    uci set firewall.vpn_forwarding_lan_out=forwarding
    uci set firewall.vpn_forwarding_lan_out.src=lan
    uci set firewall.vpn_forwarding_lan_out.dest=vpn
  4. Commit the changes:
    uci commit network
    /etc/init.d/network reload
    uci commit firewall
    /etc/init.d/firewall reload

Configure OpenVPN

Traditional (TUN) Server

echo > /etc/config/openvpn # clear the openvpn uci config
uci set openvpn.myvpn=openvpn
uci set openvpn.myvpn.enabled=1
uci set openvpn.myvpn.verb=3
uci set openvpn.myvpn.port=1194
uci set openvpn.myvpn.proto=udp
uci set openvpn.myvpn.dev=tun
uci set openvpn.myvpn.server='10.8.0.0 255.255.255.0'
uci set openvpn.myvpn.ca=/etc/openvpn/ca.crt
uci set openvpn.myvpn.cert=/etc/openvpn/my-server.crt
uci set openvpn.myvpn.key=/etc/openvpn/my-server.key
# uci set openvpn.myvpn.dh=/etc/openvpn/dh2048.pem
uci set openvpn.myvpn.dh=/etc/openvpn/dh1024.pem
uci commit openvpn
/etc/init.d/openvpn enable
/etc/init.d/openvpn start

Server-Bridge (TAP) Server

echo > /etc/config/openvpn # clear the openvpn uci config
uci set openvpn.myvpn=openvpn
uci set openvpn.myvpn.enabled=1
uci set openvpn.myvpn.verb=3
uci set openvpn.myvpn.proto=udp
uci set openvpn.myvpn.port=1194
uci set openvpn.myvpn.dev=tap0
uci set openvpn.myvpn.mode=server
uci set openvpn.myvpn.tls_server=1
uci set openvpn.myvpn.push='route-gateway dhcp'
uci set openvpn.myvpn.keepalive='10 120'
uci set openvpn.myvpn.ca=/etc/openvpn/ca.crt
uci set openvpn.myvpn.cert=/etc/openvpn/my-server.crt
uci set openvpn.myvpn.key=/etc/openvpn/my-server.key
uci set openvpn.myvpn.dh=/etc/openvpn/dh2048.pem
uci commit openvpn
/etc/init.d/openvpn enable
/etc/init.d/openvpn start

Client

echo > /etc/config/openvpn # clear the openvpn uci config
uci set openvpn.myvpn=openvpn
uci set openvpn.myvpn.enabled=1
uci set openvpn.myvpn.dev=tun
uci set openvpn.myvpn.proto=udp
uci set openvpn.myvpn.verb=3
uci set openvpn.myvpn.ca=/etc/openvpn/ca.crt
uci set openvpn.myvpn.cert=/etc/openvpn/my-client.crt
uci set openvpn.myvpn.key=/etc/openvpn/my-client.key
uci set openvpn.myvpn.client=1
uci set openvpn.myvpn.remote_cert_tls=server
uci set openvpn.myvpn.remote="SERVER_IP_ADDRESS 1194"
uci commit openvpn
/etc/init.d/openvpn enable
/etc/init.d/openvpn start
Depending on the server you are connecting to, it may be prudent to use OpenVPN's route-nopull option to prevent the server from altering routes on your router (and potentially redirecting traffic inappropriately). This will require you to add the routes manually (advanced) by specifying them in the client config or by using a route-up/down scripts.

Or alternatively drop an openvpn configuration file into /etc/openvpn/<vpnName>.conf. You can test it in a shell with

openvpn /etc/openvpn/myVpnName.conf

Configure Clients For Your Server

Create the following OpenVPN client configuration file, save it with an .ovpn extension in the Windows or .conf in the *nix and give it to your client:

Traditional (TUN) Client

dev tun
proto udp

log openvpn.log
verb 3

ca /etc/openvpn/ca.crt
cert /etc/openvpn/my-client.crt
key /etc/openvpn/my-client.key

client
remote-cert-tls server
remote SERVER_IP_ADDRESS 1194

Server-Bridge (TAP) Client

dev tap
proto udp

log openvpn.log
verb 3

ca /etc/openvpn/ca.crt
cert /etc/openvpn/my-client.crt
key /etc/openvpn/my-client.key

client
remote-cert-tls server
remote SERVER_IP_ADDRESS 1194

Test the tunnel

Congratulations! Your OpenVPN client/server should now be operational, although traffic might not be sent over it yet, since we have not yet created routes to direct connections through the tunnel. Routes tell the client to try to find a given IP address (or a subnet of IPs) via a certain gateway. On *nix systems, your current routing table can be viewed by using:

route

Routes added by the client will be listed in the OpenVPN log.

Before configuring our server to send routes to clients, we should verify that clients can connect to the server, and then ensure they can send traffic through it by pinging the server through the tunnel.

Traditional (TUN) Server

Ping the server using:

traceroute 10.8.0.1
Aside from traffic directed to the OpenVPN server, no traffic will be sent over the server until routes are created. Using traceroute on an internet address should show traffic leaving through the client's default gateway.
traceroute 8.8.8.8 #Google-DNS server

After verifying that the connection is working, you'll want to configure your server to push routes to the clients.

Server-Bridge (TAP) Server

Traffic within the local subnet (192.168.7.XXX) will be routed through the VPN without any further configuration. Other traffic will be sent through the default gateway. Ping a client using:

traceroute 192.168.7.1 #Example IP. Change to match your local subnet.

If you only require intranet access and do not want to route normal internet (WAN) traffic through your VPN, your configuration is now complete!

Client

Unless the OpenVPN option route-nopull was specified by the client, routes pushed by the server should be in place. If route-nopull was used, only the server will be accessible. Using traceroute on any address with a route pushed by the server should result in that traffic being sent through the VPN, while other addresses should be sent through the default gateway.

The OpenVPN gateway can generally be found on *nix systems using:

ifconfig tun0
And you can then test it using:
traceroute 10.8.0.1 #Arbitrary example IP

If you are not using route-nopull, then your configuration should now be complete!


:!::!::!: This page is being rewritten, and the remainder of this HOWTO has not been updated to follow the formatting of the beginning of this HOWTO. It was written with only the Default (TUN) Server in mind, and contains some redundant configuration steps. These steps will require modification to complete. :!::!::!:

Route Only Local LAN Client Traffic Through the Tunnel

If all that is needed is to allow clients access to the local subnet (e.g., to access a server at home from work), and to leave Internet access as-is, all one needs to do is advertise the local subnet and configure the firewall to allow traffic through. First, to advertise the route:

uci set openvpn.myvpn.push='route 192.168.1.0 255.255.255.0'
uci commit openvpn
/etc/init.d/openvpn restart

In this example the subnet is 192.168.1.0/24. Adjust your configuration accordingly for your LAN. Now, the firewall has to be enabled to allow traffic from the VPN clients to the local LAN. To allow it, edit /etc/config/firewall:

## NB: this zone should have already been created in the previous setup step; just add the masq option as noted below
config zone
	option name 'vpn'
	option masq '1' ## NB: this option was added to enable forwarding out of the VPN zone
	option input 'ACCEPT'
	option forward 'ACCEPT'
	option output 'ACCEPT'
	option network 'vpn0'

## NB : this section was added
config forwarding
	option src 'vpn'
	option dest 'lan'

After editing the firewall changes, enable them by executing:

/etc/init.d/firewall reload

Route All Client Traffic Through the Tunnel

If the OpenVPN server can access the Internet, then the client has the option of routing all its IP traffic via the tunnel rather than through it's local gateway. If the tunnel is merely provide access to other subnets (e.g. to access a server at home from work), but Internet access is to remain as-is, then this is not your answer. Instead, see Routing Only Local LAN Client Traffic Through the Tunnel.

Before you do this, you should know whether your network is Scenario 1 (client and server in different subnets), or Scenario 2 (client and server in the same subnet).

In Scenario 1, the client and server are in different subnets:

  1. On the OpenVPN server, execute the following
      uci set openvpn.myvpn.push='redirect-gateway def1'        ## NB: these are single quotes
      uci commit openvpn
      /etc/init.d/openvpn restart
  2. On the OpenVPN client, execute the following:
      /etc/init.d/openvpn restart
      traceroute 8.8.8.8

Alternatively, in Scenario 2, the client and server are in the same subnet (useful for creating/testing an OpenVPN tunnel at home):

  1. On the OpenVPN server, execute the following:
      uci set openvpn.myvpn.push='redirect-gateway def1 local'  ## NB: these are single quotes
      uci commit openvpn; /etc/init.d/openvpn restart
  2. On the OpenVPN client, execute the following:
      /etc/init.d/openvpn restart
      traceroute 8.8.8.8  

:!: If your OpenVPN client is not to route all it's traffic via the server (and therefore continue to use it's existing default gateway), then you should not push the redirect-gateway option at all.

You might need to make OpenWrt route traffic from vpn to wan. Add to /etc/config/firewall:

config forwarding
	option src 'vpn'
	option dest 'wan'
This worked for BB RC2 (uci commands would be better).

Another way to accomplish routing all client traffic through the tunnel via LUCI is to navigate to Network → Firewall and make the options look like this:

LAN: (lan: images) => VPN   :   accept accept accept (just changing this one to point to VPN instead of WAN)
WAN: (wan: images) => REJECT :  reject accept reject (no changes here)
VPN: (vpn: image) => WAN : accept accept accept (change forwarding to accept, check masquerading option)

Once this is working, head to vpn.server.openvpn.tun for more OpenVPN 'recipes'.

Troubleshooting

If something doesn't work as expected while following this HOWTO:

  • Check that the client can ping the server:
    ping SERVER_IP_ADDRESS
  • Check that the OpenVPN daemon is running:
    ps | grep "openvpn"
  • Check that there is a TUN interface:
    ifconfig | grep "tun"
  • Check the log:
    cat /tmp/openvpn.log
  • You can try temporarily disabling the firewall on the OpenVPN server:
    /etc/init.d/firewall stop
  • You can clear the OpenVPN configuration and start again from scratch:
    echo > /etc/config/openvpn

Asking for help

You can ask for help on the OpenWrt forum: https://forum.openwrt.org/.

When asking for help, you should at a minimum include the contents of the following files:

cat /tmp/openvpn.log
cat /etc/config/network
cat /etc/config/firewall
cat /etc/config/openvpn

Caveats

Client Config Dir

When using UCI, you need to define the client config dir differently. All OpenVPN manuals tell you write it out as client-config-dir (with dashes), but for UCI you need to call it client_config_dir (with underscores). If unsure, check the openvpn conf file that is generated in /var/etc/, as that will have client-config-dir (with dashes) when all went well.

References and examples

Additions

You may create text config file, for example /etc/openvpn/server, /etc/openvpn/client and next include it in the openvpn instance in the /etc/config/openvpn:

uci set openvpn.myvpnserver.config=/etc/openvpn/myvpnserver.conf
You may use included file and other tokens simultaneous, for example:
uci set openvpn.myvpnserverudp.config=/etc/openvpn/common.conf
uci set openvpn.myvpnserverudp.proto=udp
uci set openvpn.myvpnservertcp.config=/etc/openvpn/common.conf
uci set openvpn.myvpnservertcp.proto=tcp

FIXME: Integrate any useful information from vpn.howto.
doc/howto/vpn.openvpn.1480649291.txt.bz2 · Last modified: 2016/12/02 04:28 by ExaltedVanguard