Graph amount of OpenVPN users to Munin

Rather simple script. Using log file instead of management interface.

vpnusers-day

Part has to run as Root (due to Munin most likely not having access to read the log files. Working with the management interface could solve this.

Create /usr/local/bin/getVpnUsers.sh:

#!/bin/bash
echo "VPN.value `cat /var/log/openvpn-status.log | sed -e '1,/Common Name/d' | 
sed -e '/ROUTING TABLE/,$d' | wc -l`" > /tmp/.vpn_munin.txt

You can change the name of VPN.value to the VPN name and/or add multiple lines (each with a different NAME.value if you’re running more than one VPN user. Be sure to cat the right log file).

And:

chmod +x /usr/local/bin/getVpnUsers.sh

Add this to root cron:

*/5 * * * * /usr/local/bin/getVpnUsers.sh >/dev/null 2>&1

Now create /etc/munin/plugins/vpnusers:

#!/bin/sh

case $1 in
 config)
 cat <<'EOM'
graph_category network
graph_title oVPN users
graph_vlabel users
VPN.label My oVPN
# add more labels like this:
#isazi.label Isazi VPN
EOM
 exit 0;;
esac

cat /tmp/.vpn_munin.txt

And:

chmod +x /etc/munin/plugins/vpnusers

You’ll need the correct NAME.label in the plugin depending on the name you choose in part one.

And restart munin-node:

/etc/init.d/munin-node restart

That’s it.

Check your Munin under “network”. It might take ~15+ minutes before the graph is generated.

vpnusers-day-1

OpenVPN: Can’t assign requested address

For no clear reason, OpenVPN on Mac with Tunnelblick (any version, had this problem for a few years already) results in these kind of error messages (and refuses to connect):

2013-02-05 17:44:31 write UDPv4: Can't assign requested address (code=49)
2013-02-05 17:44:33 write UDPv4: Can't assign requested address (code=49)

This seems to appear more often when swapping WiFi/IP range (after my Mac goes into sleep). But also happens when connecting to the same WiFi. It doesn’t change anything whether I disconnect OpenVPN before putting the Mac to sleep.

The solution I’ve found to solve this is:

  1. Disconnect OpenVPN (via Tunnelblick)
  2. Turn off WiFi
  3. Run the script I’ve attached below (flush.sh)
  4. Fill in your admin/sudo password
  5. Hit ctrl+C if it doesn’t exit instantly (happens in 99% of the cases)
  6. Run the script once or twice more to be sure, it will exit correctly this time
  7. Reconnect to the WiFi
  8. Reconnect OpenVPN (via Tunnelblick): this time it will work

The script (name it flush.sh, chmod +x, and run ./flush.sh via Terminal):

Edit: updated script (29/01/2014)

#!/bin/bash
# Change IFACE to match your WiFi interface 
# (en0 on Macbook Air and Retina, en1 on old Macbook Pros with ethernet) 
IFACE=en0
sudo ifconfig $IFACE down
sudo route flush
sudo ifconfig $IFACE up

In case the script hangs (sometimes, route flush hangs): hit ctrl+C, and execute it again.

OpenVPN packet drops

I recently started to notice following error messages on my openVPN server.

ovpn-server[6306]: vpn.rootspirit.com/85.234.x.y:62068 MULTI: packet dropped due to output saturation (multi_process_incoming_tun)

This basically means that the TUN or TAP interface is making more packets than the real (TCP) interface can handle.

As I need to run OpenVPN using the TCP protocol (instead of the faster UDP protocol; as UDP is often blocked in networks I use my VPN in) I experimented by increasing the tcp-queue-limit. The default is 64, and I’ve set it to 256. So far, everything still seems to be working fine (but more packets will be queued before being dropped by OpenVPN, requiring less retransmissions).

Add this to the OpenVPN server config:

tcp-queue-limit 256

And restart the daemon.

OpenVPN & Windows 7

There’s a great GUI out for OpenVPN & Windows, located here.

However, this GUI includes an old OpenVPN, that is no longer compatible with Windows 7 and Windows Vista.

The TUN/TAP driver will be blocked due to compatibility issues, and when trying to connect to a VPN, you’ll get an error along the lines of:

All TAP-Win32 adapters on this system are currently in use

The simplest fix, is to install the GUI package (including the old OpenVPN binaries), and reinstall OpenVPN afterwards.

You can find the latest OpenVPN binaries here and the latest version, when writing this post here.

This will overwrite the old files and update the driver with a Windows 7 compatible driver.

Try to connect now, everything should work like a charm. 🙂

http://openvpn.se/download.html

OpenVPN Linux + Mac howto

A short howto, as I was unable to find any clear ones on the net.

I’m using Mac OS X (Leopard) as client, and a Gentoo server as server/host.

I both tried Viscosity and Tunnelblick on my Mac as OpenVPN software, and Viscosity is probably somewhat easier to configure (using the GUI), it was shareware. So I ended up using Tunnelblick and it seems to be doing its job quite well.

First of all, make sure Gentoo is set up and working as intended. I used my home router as VPN server (having both eth0 and eth1 (= ppp0).

Using this howto, you’ll be able to get the server up and running.

Besides the installation, and perhaps (config) file locations it should be pretty similar on other Linux distros.

As I have dnsmasq running on my server (taking care of DNS) I added the following to the server.conf:

push "dhcp-option DNS 10.0.0.1"
push "redirect-gateway def1"
client-config-dir ccd
route 10.20.30.0 255.255.255.252

Don’t forget to allow DNS requests over tun0 interface in dnsmasq.conf.

The first line tells the server to hand out 10.0.0.1 as DNS server to its connecting clients (10.0.0.1 being the internal eth0 IP of my server).

The 2nd line, tells all clients to route ALL of their traffic through the VPN. I used the VPN to access a website that allowed only Belgian IPs, and I was in The Netherlands at the time I had to access the site (Skynet’s Rock Werchter stream). So I connected through my server at home.

And the 3rd and 4th line are needed if the client access the VPN is on a private IP subnet (like being connected on a WiFi router, using IP 192.168.178.x).

You’ll have to add, in the client-config directory a file per username connecting to the VPN with something similar to this:

iroute 192.168.178.0 255.255.255.0

I’m not entirely sure if you can add multiple iroutes; something I’ll have to figure out when being on a different network.

This is what my client config looks like (vpn-server-name.conf, located in ~/Library/openvpn/):

client
dev tun
proto udp
remote home.tiete.be 9000
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1200
persist-key
persist-tun
ca "ca.crt"
cert "yeri.crt"
key "yeri.key"
tls-auth "ta.key" 1
comp-lzo
verb 3

Yeri being my username. Don’t forget to download and add the ca.crt, user.crt, user.key (located in /usr/share/openvpn/easy-rsa/keys/) and ta.key (located in /etc/openvpn/) you’ve created on the server.

If your client asks for “directions”, pick 1.

Start up server and client software.

Hitting connect in Tunnelblick should connect you to the VPN server, and (in my case) giving me an IP similar to 10.20.30.6. You can check this using “ifconfig” in Terminal.

Client:

tun0: flags=8851 mtu 1500
	inet 10.20.30.6 --> 10.20.30.5 netmask 0xffffffff
	open (pid 20551)

Server:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.20.30.1  P-t-P:10.20.30.2  Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
RX packets:407595 errors:0 dropped:0 overruns:0 frame:0
TX packets:574351 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:27473209 (26.2 MiB)  TX bytes:603524377 (575.5 MiB)

Don’t forget; when using “tun” as driver, your gateway/VPN server will always have the IP ending on .1 (e.g.: 10.20.30.1).

Now, if you want to route all traffic throug the VPN, like I did, you’ll have to change some stuff in iptables (as the server is also acting as my home router, I already did have a few rules in it).

Allow all traffic through tun0 interface:

iptables -A OUTPUT -o tun0 -j ACCEPT
iptables -A INPUT -i tun0 -j ACCEPT

Allow traffic through the external port 9000 (UDP):

iptables -A INPUT -i ppp0 -p udp -m udp --dport 9000 -j ACCEPT

Enable forwarding and NAT:

iptables -A FORWARD -s 10.20.30.0/24 -i tun0 -j ACCEPT
iptables -A FORWARD -d 10.20.30.0/24 -i ppp0 -j ACCEPT
iptables -A POSTROUTING -o ppp0 -j MASQUERADE

And lastly, as I have Squid running on my server, I want to transparently forward all port 80 requests to the Squid server running on port 8080:

iptables -t nat -A PREROUTING -i tun0 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8080

That’s about it. You should have a running VPN from your current location to your VPN server. And you’re able to use it as a gateway.

You can always traceroute/tracepath to your VPN server (10.20.30.1). It should only find one hop.