VLAN trunking with Cisco Catalyst 2950 + WAP4410N


On the 2950, configure the port to the WAP4410N as trunk :

switch#conf t
switch(config)#interface fastEthernet 0/12
switch(config-if)#description WAP4410N
switch(config-if)#switchport trunk native vlan 30
switch(config-if)#switchport trunk allowed vlan 10,20,30
switch(config-if)#switchport mode trunk

By default all VLAN are allowed on a trunk. It is recommended to specify which VLAN you want on the trunk.

Native VLAN will be the VLAN of any untagged frame. This is somewhat useless here as WLAN are tagged.

Review the configuration :

switch#show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Fa0/12      on           802.1q         trunking      30

Port      Vlans allowed on trunk
Fa0/12      10,20,30

Port        Vlans allowed and active in management domain
Fa0/12      10,20,30

Port        Vlans in spanning tree forwarding state and not pruned
Fa0/12      10,20,30

Configure the WAP4410N as such :
Screen Shot 2013-06-30 at 11.12.06

The IP in “Setup > Basic Setup” should be in the subnet of VLAN 20. It allows you to manage the unit remotely.

Under “Administration > Management” make sure you enable “Wireless web access”.

Find IP ranges from an ASN

$ whois | grep origin:
origin: AS5432

$ whois -h whois.ripe.net -i origin -T route AS5432 | grep -w "route:" | awk '{print $NF}' |sort -n

Related : Find IP ranges for a country

Debugging Multicast

On the “client” side :
iperf -u -c -p 10000 -b 1 -i 5 -T 10 -t 120

-u : use UDP
-c : run in client mode
-p : port
-b : bandwidth in bits/sec
-i : interval in second
-T : TTL
-t : time to transmit in seconds

On the “server” side :
iperf -s -i 1 -u -B -p 10000

-s : run in server mode
-B : bind to multicast address

Force IP renewal on Cisco 837

Belgacom ISP force IP renewal for their residential ADSL customers every 36 hours for whatever stupid purpose (annoy us, sell their fixed IP option, etc.).

Here’s how I force my Cisco 837 router to renew its WAN IP every night at 01:00am :

kron occurrence RENEW_IP at 1:00 recurring
 policy-list RENEW_IP

kron policy-list RENEW_IP
 cli clear interface Dialer 1

I’m less likely to lose my SSH/VPN connections now..

Local user authentication with FreeRADIUS

This one is a bit less complex than http://blog.wains.be/index.php/2009/09/13/wpa2-freeradius-eap-tls/

This is actually the most basic RADIUS configuration ever, useful for quick tests. I can only recommend checking the post mentioned above if you want to do something serious.

# apt-get install freeradius

# vim /etc/freeradius/users

login     Cleartext-Password := "password"
login2     Cleartext-Password := "password2"
#vim /etc/freeradius/clients.conf

client localhost {
	ipaddr =
        secret = radiuspassword

client router {
	ipaddr =
        secret = radiuspassword

# /etc/init.d/freeradius restart

Check if RADIUS is working :

# radtest login password localhost 1812 radiuspassword
Sending Access-Request of id 222 to port 1812
User-Name = "login"
User-Password = "password"
NAS-IP-Address =
NAS-Port = 1812
rad_recv: Access-Accept packet from host port 1812, id=222, length=20

# radtest login2 password2 localhost 1812 radiuspassword
Sending Access-Request of id 1 to port 1812
User-Name = "login2"
User-Password = "password2"
NAS-IP-Address =
NAS-Port = 1812
rad_recv: Access-Accept packet from host port 1812, id=1, length=20

We expect Access-Accept from the server, not Access-Reject…

Configure your wireless access point :

Usually found under Security tab (or RADIUS, 802.1X, etc.)
Configure your device at to authenticate against the Radius server with password radiuspassword.
Try to connect to your wireless access point using login and password.


WPA/WPA2 Enterprise on your wired or wireless network. Tested under Debian Lenny (server side) and Mac OS X 10.6, Windows XP and Android 2.2, Ubuntu 10.10 (client side)


This step is not needed anymore, starting from Debian Squeeze Freeradius comes with TLS support.
Please, do not build stuff on your production server. Build on a dedicated build machine and then install the resulting packages on the production server.

If you are running Debian Lenny on i386, you can skip the build steps and grab the packages at this address :

Let’s proceed…

Install the necessary packages :

apt-get install dpkg-dev fakeroot

Download the source :

cd /root
mkdir freeradius-tls
cd freeradius-tls
apt-get source freeradius

Make the changes :

Edit /root/freeradius-tls/debian/rules :

and change
for eap_tls, eap_ttls, eap_peap and openssl

Just as :
--with-rlm_sql_postgresql_lib_dir=`pg_config --libdir`
--with-rlm_sql_postgresql_include_dir=`pg_config --includedir`

Then, comment the following :
for pkg in ${pkgs} ; do
if dh_shlibdeps -p $$pkg -- -O 2>/dev/null | grep -q libssl; then
echo "$$pkg links to openssl" ;
exit 1 ;
fi ;

Edit /root/freeradius-tls/debian/control :
On the line beginning by “Build-Depends”
Add the folowing :
", libssl-dev"
at the end of the line (without the quotes)

Install dev libraries :
apt-get install libssl-dev debhelper libgdbm-dev libiodbc2-dev libkrb5-dev libldap2-dev libltdl3-dev libmysqlclient15-dev libpam0g-dev libpcap-dev libperl-dev libpq-dev libsasl2-dev libsnmp-dev python-dev

Build freeradius :
dpkg-buildpackage -rfakeroot

Building will end by a warning message, this is not important.

Put the packages on hold to avoid upgrading with a non-TLS version of FreeRADIUS :

echo "freeradius hold" | dpkg --set-selections
echo "libfreeradius2 hold" | dpkg --set-selections
echo "freeradius-common hold" | dpkg --set-selections

Install the packages we’ve just built :
dpkg --install freeradius_2.0.4+dfsg-6_i386.deb freeradius-common_2.0.4+dfsg-6_all.deb libfreeradius2_2.0.4+dfsg-6_i386.deb


Creating the CA

apt-get install openssl

Edit /etc/ssl/openssl.cnf

[ CA_default ]
dir = ./PKI

Edit /usr/lib/ssl/misc/CA.sh


Then type :

cd /etc/ssl
/usr/lib/ssl/misc/CA.sh -newca

Set a challenge password and a passphrase. This is needed.
The CA created will be copied to the server and clients later on.

Optional : if you have Windows XP clients

Create /etc/openssl/PKI/xpextensions



Server certificate signing request :

cd /etc/ssl
openssl req -new -nodes -keyout PKI/server_key.pem -out PKI/server_req.pem -days 730 -config openssl.cnf

Set a challenge password

Sign the server certificate request :
cd /etc/ssl
openssl ca -config openssl.cnf -policy policy_anything -out PKI/server_cert.pem -infiles PKI/server_req.pem

Then :
cp PKI/server_cert.pem PKI/server_cert.pem-backup

Edit server_cert.pem
Remove everything before the line —–BEGIN CERTIFICATE—– (this is needed for winxp clients)

Next :
cat PKI/server_key.pem PKI/server_cert.pem > PKI/server_keycert.pem

Create a client certificate signing request :
openssl req -new -keyout PKI/client_key.pem -out PKI/client_req.pem -days 730 -config openssl.cnf

You MUST specify a Common Name (CN).

Sign client cert request :

Windows xp client :
openssl ca -config openssl.cnf -policy policy_anything -out PKI/client_cert.pem -extensions xpclient_ext -extfile PKI/xpextensions -infiles PKI/client_req.pem
Mac OS X / Linux / Android client :
openssl ca -config openssl.cnf -policy policy_anything -out PKI/client_cert.pem -infiles PKI/client_req.pem

Export P12 certs :

Windows and Mac clients :
openssl pkcs12 -export -in PKI/client_cert.pem -inkey PKI/client_key.pem -out PKI/client_cert.p12 -clcerts

Android clients :
openssl pkcs12 -export -in PKI/client_cert.pem -inkey PKI/client_key.pem -certfile PKI/cacert.pem -name "Wifi" -out PKI/client_cert.p12

You don’t need to export P12 certificates for Linux (smart OS, eh ?)


Do :
mkdir /etc/freeradius/certs/
cp /etc/ssl/PKI/cacert.pem /etc/freeradius/certs/cacert.pem
cp /etc/ssl/PKI/server_keycert.pem /etc/freeradius/certs/server_keycert.pem

Then :
cd /etc/freeradius/certs
openssl dhparam -check -text -5 512 -out dh
dd if=/dev/urandom of=random count=2
chown freerad dh
chmod o-w dh

Next :
cp /etc/freeradius/eap.conf /etc/freeradius/eap.conf-default

/etc/freeradius/eap.conf :

eap {
        default_eap_type = tls
        timer_expire     = 60
        ignore_unknown_eap_types = no
        cisco_accounting_username_bug = no         

        tls {          
                certdir = ${confdir}/certs
                cadir = ${confdir}/certs
                private_key_password = whatever
                private_key_file = ${certdir}/server_keycert.pem
                certificate_file = ${certdir}/server_keycert.pem
                CA_file = ${cadir}/cacert.pem
                dh_file = ${certdir}/dh
                random_file = ${certdir}/random
                fragment_size = 1024
                include_length = yes
                check_cert_cn = %{User-Name}
                cipher_list = "DEFAULT"

Edit /etc/freeradius/clients.conf

We will consider the access-point that will authenticate users against the RADIUS server has the IP :

client localhost {
        ipaddr =
        secret          = testing123
        require_message_authenticator = no
        nastype     = other     # localhost isn't usually a NAS...

client {
        secret = suchasecurepassword
        shortname = linksys

Start FreeRADIUS :

The first time it is recommended to launch with the following command, this gives a lot of output.
freeradius -X -f

When everything is fine and clients are happy, start the service the usual way :
/etc/init.d/freeradius start

Set up wifi access point for authentication against our new RADIUS server

It depends on your hardware here.
You must usually go under the security panel of your device, where you can specify the IP/hostname and port of the RADIUS server, and the password (in our example : suchasecurepassword).

Make sure your firewall lets the Wi-Fi access point talk to FreeRADIUS on port UDP/1812.

Configure clients

You’ll need the following files for the following platforms :

Mac OS X : P12 certificate (cert + private key), PEM CA certificate
Windows XP : P12 certificate (cert + private key), PEM CA certificate
Android 2.2 : P12 certificate (cert + private key + CA) (see http://blog.wains.be/index.php/2011/03/13/importing-certificates-on-android-ca-and-client/)
Linux Ubuntu 10.10 (Network Manager) : PEM certificate, PEM private key, PEM CA certificate

This post is a stripped down version of the following howto by my colleague Jérôme :

NetworkManager and resolv.conf

I’m under Debian Lenny at work.

I installed the VPNC plugin (Cisco VPN) for NetworkManager today.
I usually always connect to OpenVPN tunnels with the OpenVPN plugin, which works pretty well (at least on NM 0.6.6).

After installing the VPNC plugin, I started having issues with my OpenVPN tunnels.. I was not able to resolve remote hostnames correctly.

The problem was that my resolv.conf didn’t get updated upon connection to the OpenVPN.

When installing network-manager-vpnc-gnome, a dependency named “resolvconf” got installed along. The package somewhat protected /etc/resolv.conf from being updated.

After getting rid of resolvconf, my OpenVPN VPNs are working again !
Also, this didn’t prevent the Cisco VPN from working..

I need to check out what that resolvconf package is all about.. if someone has a clue, please comment :)

A VPN for remote users with OpenVPN

This article quickly explains how to set up a VPN for your remote users based on OpenVPN in around 5 minutes.
If you want detailed informations about OpenVPN, certificates or other stuff, this is not the right place.

This applies to Debian Etch but will work will little difference in paths under Red Hat.

On the server

Install OpenVPN and the dependencies :
# apt-get install openvpn

Copy the scripts that will help us generate all the necessary files (certificates, keys, etc.) :

Under Debian :
# cp -aR /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/pki

Under RedHat :
# cp -aR /usr/share/doc/openvpn-2.0.9/easy-rsa/2.0 /etc/openvpn/pki

Let’s start :
# cd /etc/openvpn/pki

Edit the variables :
# vim vars

export KEY_ORG=”Green Company, LLC”
export KEY_EMAIL=”admin@example.org”

Set the scripts executable :
# chmod +x *

Source the variables :
# . ./vars

Set up the keys environment :
# ./clean-all

Build the certificate authority (CA) :
# ./build-ca

Build the certificate and private key for the server :
# ./build-key-server server

It’s not necessary to set a password.

Then, build the Diffie Hellman file :
# ./build-dh

Build the client certificate for your first user :
# ./build-key-pass client1

You’ll be asked questions about the client.

Now under /etc/openvpn/pki/keys you must find a bunch of files.

Copy the files necessary for the server on the server under /etc/openvpn :

Do so with a single command :
# cp /etc/openvpn/pki/keys/{server.crt,server.key,dh1024.pem,ca.crt} /etc/openvpn

Send the following files to the client, store them wherever pleases you :

Send the following configuration to the user “client1″ (vpn.conf which would reside in the same directory as the certificates and key) :

remote vpn.example.org
port 10000
proto udp
dev tun



resolv-retry infinite
ns-cert-type server

verb 3

ca      ./ca.crt
cert    ./client1.crt
key     ./client1.key


#up 	./up.sh
#down 	./down.sh

ping 10
ping-restart 60

The up and down scripts are respectively executed when the connection is opened and closed.
You can for example change the name server the client will use when connected to the VPN using those scripts (or opening ports in the firewall, etc.).

Server (/etc/openvpn/vpn.conf on the server) :

port    10000
proto   udp
dev-type     tun
dev vpn-user

ca      ca.crt
cert    server.crt
key     server.key
dh      dh1024.pem

# enable compression

# allow several users to connect with the same certificate


keepalive 10 120

push 	 	"dhcp-option DOMAIN local.example.org"
push 	 	"dhcp-option DNS"


user nobody
group nogroup

log vpn.log
verb 1

The server will “push” the DNS settings to the client, this will modify your /etc/
resolv.conf so you will use the DNS server and hostname resolution of your office (or whatever place you are connecting to) when connected to the VPN.

On the server, make sure openvpn starts at boot by uncommenting the following line under /etc/default/openvpn (Debian) :

When done, restart OpenVPN on the server :
# /etc/init.d/openvpn restart

Now, connect from the client (as root, or use sudo) from a remote network :
# openvpn --config vpn.conf

The client will get an IP in the range 10.30.0.x on the device tun0, it will add a route to the range through the VPN (172.30.x.x in this example is supposed to be the network subnet on the server side).

DHCP and Dynamic DNS with BIND

Tested under Debian Etch

This is the network configuration of our DHCP/DNS server

Hostname : router.static.example.org
WAN interface (eth0) : mask
LAN interface (eth1) : mask
Default gateway :

First, we need to tell the DHCP server to only run on eth1 :

/etc/default/dhcp3-server :


/etc/dhcp3/dhcpd.conf :

This is the DHCP server configuration.

When a computer requests network information from the DHCP server, the DHCP will update the DNS zones
– dyn.example.org : the zone that will map hostnames to IP address
– 201.30.172.in-addr.arpa : the zone in charge of reverse lookups

ddns-domainname is the domain name that the DHCP server will try to update in the zone. For example if my computer is named mycomputer, it will try to upload the dyn.example.org zone with mycomputer.dyn.example.org.

That option is absolutely needed if you have several domains in the “option domain-name” field (the “search” domains that will be in /etc/resolv.conf), or it could try to add the hostname mycomputer.static.example.org to the dyn.example.org zone.

If you only have one domain in the “option domain-name” field, you can go without ddns-domainname as it will upload the zone with the domain specified there.

ddns-update-style interim;
include "/etc/bind/rndc.key";

zone dyn.example.org. {
        key "rndc-key";

ddns-domainname "dyn.example.org";
option domain-name "static.example.org dyn.example.org";
option domain-name-servers;
option routers;
option broadcast-address;
option ntp-servers;

default-lease-time 86400;
max-lease-time 86400;


log-facility local7;

subnet netmask {


        # DNS zones to update
        zone 201.30.172.in-addr.arpa. {
                key "rndc-key";

        zone dyn.example.org. {
                key "rndc-key";

/etc/bind9/named.conf :

Make sure the file contains the following :
include "/etc/bind/named.conf.local";

You should not change that file, as you will specify your options in two other files.

/etc/bind9/named.conf.options :

Your options.
The zone files will be stored under /var/cache/bind/
The queries for unauthoritative domains will be forwarded to You can put the DNS provided by your ISP there (or put the DNS from opendns.com)

options {
        directory "/var/cache/bind";

        query-source address * port 53;

        forwarders {

        recursion yes;

        version "REFUSED";

        allow-recursion {

        allow-query {


/etc/bind9/named.conf.local :

This will contain your zone declarations

### options #########

include "/etc/bind/rndc.key";
controls {
        inet allow { localhost; } keys { "rndc-key"; };

### "static" zones #########

zone "static.example.org" {
        type master;
        file "db.static.example.org";

zone "200.30.172.in-addr.arpa" {
        type master;
        notify no;
        file "db.172.30.200";

### dynamic zones (updated by DDNS) #########

zone "dyn.example.org" {
        type master;
        file "db.dyn.example.org";
        allow-update { key "rndc-key"; };

zone "201.30.172.in-addr.arpa" {
        type master;
        notify no;
        file "db.172.30.201";
        allow-update { key "rndc-key"; };

Now let’s focus on DNS zones.

In this example we have several zones :

– static.example.org : static zone (like servers with static IP’s)
– dyn.example.org : dynamic zone, updated by DHCP when a computer gets an IP from it
– 172.30.200 : static zone (servers, etc.), which is not updated by DDNS
– 172.30.201 : dynamic zone, will contain information about machines using DHCP

I advise to split the static zones from the dynamic zones, DDNS has a tendency to mess up the zone files, which make them barely readable and manageable.

/var/cache/bind/db.172.30.200 :

$TTL 86400	; 1 day
200.30.172.in-addr.arpa	IN SOA	static.example.org. postmaster.example.org. (
				200806299  ; serial
				28800      ; refresh (8 hours)
				7200       ; retry (2 hours)
				2419200    ; expire (4 weeks)
				86400      ; minimum (1 day)
			NS	ns.static.example.org.
$ORIGIN 200.30.172.in-addr.arpa.
253			IN PTR	server.static.example.org.
254			IN PTR	router.static.example.org.

/var/cache/bind/db.172.30.201 :

$TTL 86400	; 1 day
201.30.172.in-addr.arpa	IN SOA	static.example.org. postmaster.example.org. (
				200806327  ; serial
				28800      ; refresh (8 hours)
				7200       ; retry (2 hours)
				2419200    ; expire (4 weeks)
				86400      ; minimum (1 day)
			NS	ns.static.example.org.
$ORIGIN 201.30.172.in-addr.arpa.

/var/cache/bind/db.static.example.org :

$TTL 86400	; 1 day
static.example.org	IN SOA	ns.static.example.org. postmaster.example.org. (
				200806327  ; serial
				28800      ; refresh (8 hours)
				7200       ; retry (2 hours)
				2419200    ; expire (4 weeks)
				86400      ; minimum (1 day)
			NS	ns.static.example.org.
$ORIGIN static.example.org.
server			A
router			A
ns			A

ntp			CNAME	router.static.example.org. 
smtp			CNAME	router.static.example.org.


$TTL 86400	; 1 day
dyn.example.org		IN SOA	ns.static.example.org. admin.example.org. (
				200806341  ; serial
				28800      ; refresh (8 hours)
				7200       ; retry (2 hours)
				2419200    ; expire (4 weeks)
				86400      ; minimum (1 day)
			NS	ns.dyn.example.org.
$ORIGIN dyn.example.org.

Now, make sure the zones will be writable by the user “bind” and restart the services :

# chown bind. /var/cache/bind/*
# /etc/init.d/bind restart
# /etc/init.d/dhcp3-server restart

On a computer on the network :

As root :

Edit /etc/dhcp3/dhclient.conf and set :
send host-name "mycomputer";

Now request an IP :
# dhclient eth0

Let’s imagine the computer has received the IP

You should see on the server’s syslog that the DNS zones have been updated.

– mycomputer.dyn.example.org is now bound to
– will return mycomputer.dyn.example.org

From your computer, you should be able to verify the zones have been updated properly :

$ nslookup mycomputer

Name:	mycomputer.dyn.example.org
$ nslookup
Address:	name = mycomputer.dyn.example.org.

You don’t need to type the whole mycomputer.dyn.example.org thing since it will lookup for either :
– mycomputer.dyn.example.org
– mycomputer.static.example.org if the previous wasn’t found
– mycomputer if the previous two were not found

This actually means that if you lookup www.google.be, it would try to resolve www.google.be.dyn.example.org first, then www.google.be.static.example.org, and finally www.google.be

You can avoid those unnecessary lookups by adding a dot to the end of the hostname you are trying to resolve :

# nslookup www.google.be.

This is the purpose of the search domains in /etc/resolv.conf

Pay attention to the syntax in /etc/resolv.conf.
You should be able to specify up to 6 domains to look up automatically.
Each domains should be on one line, separated by spaces.
I made a mistake and had domains separated by commas.
It was working perfectly fine with up to 2 domains on the search line.
With 3 domains or more, the computer would just not try to resolve on the domains at all.

Routed OpenVPN between two subnets behind NAT gateways

Edit : between two or MORE subnets. Check out the exchange between Michael Antal and me in the comments. He’s been able to interconnect 3 subnets using this method and some slight tweaks in routes.

The following is the configuration needed to create a routed OpenVPN network between two remote subnets, both behind NAT gateways. On each side, the gateways will act as the VPN gateways.

Network subnets on both side must be different. In this example, we connect to

With this setup, we don’t even need to open ports at the NAT level on either side of the VPN.

Network configuration

Network A :

Subnet :

Gateway for Network A
VPN interface (tun0) :
Eth0 :
Eth1 / Public IP : 212.x.x.x (machineA.example.org)

Network B :

Subnet :

Gateway for Network B
VPN interface (tun0) :
Eth0 / Public IP : 66.x.x.x (machineB.example.org)
Eth1 :

If we imagine forwarding is rejected at the firewall level on machine B, we would need to allow traffic between the tun device created by OpenVPN and the LAN interface, as root you would then type :
iptables -I FORWARD -i tun0 -o eth1 -j ACCEPT
iptables -I FORWARD -i eth1 -o tun0 -j ACCEPT

Make sure the rules remain applied across reboots (using iptables-save or storing the rules in /etc/rc.local or else)

Enabling IP routing :

We need to enable routing on both VPN gateways..

echo “1” > /proc/sys/net/ipv4/ip_forward

Using this method, routing is not persistent across reboots, check the following link :
http://blog.wains.be/index.php/2006/06/06/enable-ip-forward-under-rhelcentos/ (which works for Debian as well)

Static key generation :

We will use simple static key for our example…

openvpn --genkey --secret /etc/openvpn/vpn.key

Share the key between the VPN gateways over a secure channel (scp, etc.).

If you want to use certificates instead (which I recommend), check out : http://blog.wains.be/index.php/2008/07/15/a-vpn-for-remote-users-with-openvpn/

OpenVPN configuration :

machine A : /etc/openvpn/vpn.conf

remote machineB.example.org
port 8000
dev tun
ping 15
secret /etc/openvpn/vpn.key
chroot /var/empty
user nobody
group nogroup
# If using RedHat replace with
# group nobody
log vpn.log
verb 1

machine B : /etc/openvpn/vpn.conf

remote machineA.example.org
port 8000
dev tun
ping 15
secret /etc/openvpn/vpn.key
chroot /var/empty
user nobody
group nogroup
# If using RedHat replace with
# group nobody
log vpn.log
verb 1

Establishing the connection :

On machine A type :

openvpn --config /etc/openvpn/vpn.conf

Machine A will try to establish the connection. Type the same command on machine B to initialize the connection.

As soon as the connection is up, hosts on network A should be able to ping hosts on network B and vice-versa. If you can’t ping from one side to the other, it’s probably a routing issue.

We can use traceroute from a machine on network A to see the path taken to reach a host on network B :

$ traceroute
traceroute to (, 30 hops max, 40 byte packets
1 ( 2.128 ms 2.378 ms 2.781 ms
2 ( 132.761 ms 137.342 ms 141.130 ms
3 ( 136.752 ms 133.869 ms 135.960 ms

We can see the traffic is going through the interface.

We also can check the routing table on the VPN gateway on network A :

# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface UH 0 0 0 tun0 U 0 0 0 eth0 UG 0 0 0 tun0 212.x.x.x UG 0 0 0 eth1

We see any traffic directed to must go through interface on device tun0.

Making sure the VPN connection is established at boot (Debian way) :

Edit /etc/defaults/openvpn and specify which VPN network must be started.

Make OpenVPN starts at boot with this command :

update-rc.d openvpn defaults

OpenVPN will start any VPN configuration named *.conf found in /etc/openvpn/
So don’t store copies of config like test.conf test-backup.conf as OpenVPN will try to start them at boot.