OpenVPN is a service to host your own VPN server, without using third-party servers.
A VPN is a secured connection between two networks, for example between your phone and your home.
In this tutorial, I’ll give you a step-by-step method to install it quickly on Raspberry Pi.
Source: The Easiest Way to Install OpenVPN Server on Raspberry Pi – RaspberryTips
OpenVPN is a full-featured, open-source Secure Socket Layer (SSL) VPN solution that accommodates a wide range of configurations. In this tutorial, you will set up an OpenVPN server on an Ubuntu 18.04 server and then configure access to it from Windows, macOS, iOS and/or Android. This tutorial will keep the installation and configuration steps as simple as possible for each of these setups.
Source: How To Set Up an OpenVPN Server on Ubuntu 18.04 | DigitalOcean
BBC Click’s Kate Russell gives a step-by-step guide to setting up your own virtual private network using a Raspberry Pi.
Source: How to set up your own Raspberry Pi powered VPN – BBC News
About
Shell script to set up Raspberry Pi (TM) as a VPN server using the free, open-source OpenVPN software. Includes templates of the necessary configuration files for easy editing, as well as a script for easily generating client .ovpn profiles after setting up the server. Based on the ReadWrite tutorial ‘Building A Raspberry Pi VPN’ by Lauren Orsini (see sources 1 and 2 at the bottom of this Readme).
To follow this guide, you will need to have a Raspberry Pi Model B or later (so long as it has an ethernet port), an SD or microSD card (depending on the model) with Raspbian installed, a power adapter appropriate to the power needs of your model, and an ethernet cable to connect your Pi to your router or gateway. You will also need to setup your Pi with a static IP address (see either source 3 or 4) and have your router forward port 1194 (varies by model & manufacturer; consult your router manufacturer’s documentation to do this). You should also find your Pi’s local IP address on your network and the public IP address of your network and write them down before beginning. Enabling SSH on your Pi is also highly recommended, so that you can run a very compact headless server without a monitor or keyboard and be able to access it even more conveniently (This is also covered by source 4). And last but not least, be sure to change your user password from the default.
Full documentation and download here:
OpenVPN-Setup (GitHub)
Discussion in this Reddit thread
One of the most concerning factors to me while browsing, Is how can I ensure that my data remains private and secure ? While searching for answers, I came cross a number of ways in which you can remain anonymous like using a proxy website. But still using a third party service was not assuring enough. What I needed was a software which could be installed and run by me thus ensuring that I and only I would have access to the data.
So what is such a software called?
It’s called a VPN service or short for Virtual Private Network. It allows you to encrypt your data via SSL when you connect through it. Since the connection is encrypted even your ISP cannot see what your browsing.
In this Linux Tutorial , I will be installing an OpenVPN Access Server on CentOS 7 . OpenVPN is easy to use, OpenSource and has community based support. It has clients for Windows, Android, and Mac.
Full article here:
How to install an Opensource VPN Server on Linux (techarena51.com)
We love Linux and we love it for its open source nature, security, and powerful tools. There are a lot of free as well as commercial VPN solutions available for Ubuntu. We are not going to list or rank all the top VPN providers. We don’t necessarily want to rank them simply because users choose their VPN provider based on their personal requirements. If you want an US VPN service, you should look for the best US VPN service that supports OpenVPN. The intent of the article is to help newbies configure and use their favorite VPN service without going back and forth in Ubuntu community forum and embarrass oneself before the rather patronizing users.
Full article here:
How To Setup a VPN in Ubuntu using OpenVPN (Linuxaria)
Since the demise of the free LogMeIn service, you might have lost access to your home PC. Fortunately, with the right router, and a little bit of time, you can gain free access to your home machines very easily with OpenVPN. This guide I’ve written for the DSLReports.com community will focus primarily on OpenVPN running on DD-WRT, but should apply almost equally to “TomatoVPN” firmware, or newer Asus routers which include it (I would also recommend checking out “Tomato by Shibby” — as this looks to be some great firmware for those with supported hardware).
Full article here:
OpenVPN on DD-WRT: A Secure Connection To Home Networks | DSLReports, ISP Information (DSLReports.com)
I have previously reviewed the title, “Review of OpenVPN: Building and Integrating Virtual Private Networks by Markus Feilner“, and this is the updated and expanded version of that book. The publisher says that all examples in the book work with version 2.0.9 and 2.1 of OpenVPN. Since the original book was released in 2006, it was definitely due for an update!
Here’s what the publisher wants you to know about the book (my comments will follow):
In Detail
OpenVPN is a powerful, open source SSL VPN application. It can secure site-to-site connections, WiFi, and enterprise-scale remote connections. While being a full-featured VPN solution, OpenVPN is easy to use and does not suffer from the complexity that characterizes other IPsec VPN implementations. It uses the secure and stable TLS/SSL mechanisms for authentication and encryption. This book is an easy introduction to this popular VPN application. After introducing the basics of security and VPN, it moves on to cover using OpenVPN, from installing it on various platforms, through configuring basic tunnels, to more advanced features, such as using the application with firewalls, routers, proxy servers, and OpenVPN scripting.
This is a practical guide to using OpenVPN for building both basic and complex Virtual Private Networks. It will save you a lot of time and help you build better VPNs that suit your requirements. While providing only necessary theoretical background, the book takes a practical approach, presenting plenty of examples. It starts with an introduction into the theory of VPNs and OpenVPN, followed by a simple installation example on almost every available platform. After a concise and ordered list of OpenVPN’s parameters, we dive into connecting several machines in a safe way. The last third of the book deals with professional and high-end scenarios, and also mobile integration. After having read the whole book and followed and understood all the examples, you will be an expert in VPN, Security, and especially in OpenVPN Technology. This book was written for version 2.0.9 of OpenVPN, but all examples have been tested and run smoothly on version 2.1 too.
Read the full Table of Contents for Beginning OpenVPN 2.0.9
What you will learn from this book
Approach
This book is an easy introduction to OpenVPN. While providing only necessary theoretical background, it takes a practical approach, presenting plenty of examples. It is written in a friendly style making this complex topic easy and a joy to read. It first covers basic VPN concepts, then moves to introduce basic OpenVPN configurations, before covering advanced uses of OpenVPN.
Who this book is written for
This book is for both experienced and new OpenVPN users. If you are interested in security and privacy in the internet, or want to have your notebook or mobile phone connected safely to the internet, the server in your company, or at home, you will find this book useful. It presumes basic knowledge of Linux, but no knowledge of VPNs is required.
Now back to my mini-review. If you read my original review (which explains why I think a VPN can be an important part of securing private VoIP networks, among other uses), you know that I found Mr. Feilner’s original book quite helpful in giving me a grasp on VPNs, a subject I’d known very little about prior to that point. There were a few things I thought could have been covered better, though, so I was interested to see if those things had been addressed in this updated edition.
As I had more or less noted, the author seemed to slightly prefer SuSE Linux over other versions of Linux, and the Shorewall firewall over other Linux firewall solutions, and (in my opinion) the new book still uses more pages than are really necessary talking about how to set up and configure Shorewall, but at least now the authors do provide some minimal information about the far more popular iptables firewall tool (a little over three pages). It would have been nice to see a more in-depth treatment of this subject, because sometimes setting up iptables correctly is one key to getting your VPN to work as you want it to, particularly if you need or want to do anything more complicated than a simple VPN tunnel. It’s a minor nit, to be sure, because there’s plenty of information on the web about how to set up and configure iptables, but I personally would have given that topic more than three pages.
Then I discovered they’d made one addition that I really wanted to see: A totally new chapter on OpenVPN GUI tools, and in particular, a section on Webmin’s OpenVPN plugin. My disappointment again was that this was not a more exhaustive treatment of the subject. Actually, it’s little more than a mention that the plugin exists, and a few screenshots. Granted that this was more than appeared in the original volume, and just informing readers of the existence of that plugin is no small thing, but when I did my series on Setting up an OpenVPN tunnel using a CentOS-based system as the server and a router flashed with Tomato firmware as the client, it took me two parts to explain how to configure the Webmin plugin. That same chapter also talks about some client GUI’s for Linux, but doesn’t spend more than a page or two on any of them.
I’m not really faulting the authors here — it’s very apparent that they write about what they know, and they definitely know their stuff when it comes to OpenVPN, whereas they may not be quite as familiar with Webmin or iptables. That said, Windows users should find all the information they need to set up an OpenVPN tunnel and then some, and Linux newbies get enough information to at least point them in the right direction. As for Mac users, the coverage there is about the same as in the previous edition, which is to say that there’s about three pages on how to install Tunnelblick. However, much of the information in the book is not OS specific, and those with some experience with Linux or OS X should have no trouble at all following along.
On a positive note, there are many examples and screenshots in the book, and in this one the screenshots are actually readable (well, I did need my reading glasses for a few of them, but then I’m getting to the point where I need my reading glasses to read the cooking directions on a frozen dinner!). And, the authors’ writing style is clear and easy to understand. Also, there’s a totally new (albeit relatively short) chapter on Mobile Security, which may be of interest to some of the “road warriors” out there.
So, my recommendation is this: If you read Markus Feilner’s previous book on OpenVPN and liked it, you’re almost certainly going to want to read this one, just to get up to date. If you didn’t read the previous edition but just want to get up to speed on OpenVPN, this really is one of the better books on the subject, provided that you understand that at times you may have to supplement the book with a bit of additional research on the Web, particularly if you are running OS X or Linux as your operating system (but at least you’ll have a much better handle on topics for additional research).
The reason this is a mini-review and not a full review is because due to personal/family issues I haven’t had time to do much more than skim through the new book, rather than give it a complete read as I normally prefer to do. But since Packt Publishing kindly sent me the book over a month ago, I feel as though it’s a disservice to both them and to the readers of this blog to delay mentioning it any longer. Despite my comments about the paucity of additional pages on the particular topics I’d hoped to read more about, this is still a great book for those who need to set up and secure an OpenVPN tunnel, particularly if you’re just starting out and know next to nothing about VPNs and/or OpenVPN.
Beginning OpenVPN 2.0.9 by Markus Feilner, Norbert Graf (Amazon affiliate link)
Continued from Part 3…
If you have set up an OpenVPN server on your system and are using it regularly, eventually you are going to want to trim the log file. Webmin actually makes that easy. Simply click on System, then Log File Rotation. You should see a bunch of existing log file rotation rules. Up near the top of the page there’s a line that reads:
Select all. | Invert selection. | Add a new log file to rotate.
Click on Add a new log file to rotate. You should get a page that looks like this:
The main thing here is to get the correct log file path into the topmost text area. The path will be something like:
/etc/openvpn/servers/servername/logs/openvpn.log
I generally keep all the default settings except for these two:
Rotate even if log file is empty? (I set to No)
Ignore log file if missing? (I set to Yes)
But you can do as you wish. The important thing is to make sure that the log isn’t simply allowed to grow forever Set it up as you like, click Create, and you’re through.
And now a note for FreePBX and Asterisk users. When setting up an extension, if you use the permit and deny fields to enhance security, the correct way to fill these out may not be intuitive. For example, if you do sip show peers from the CLI, an extension at the client end of the tunnel may show up with an address in the range of addresses assigned by the client router (such as 192.168.5.x) and yet when you fill out the permit field, using that address may not work. Asterisk’s log file will generally tell you the address it wants to see, and in our case that was 10.8.0.10! No, I don’t know why, but just wanted to give you a “heads up” on that one.
I had mentioned in Part 3 some of the things that needed to be done if, from machines on the server side of the VPN tunnel, you wanted to be able to access machines at the client network (where the router with the Tomato firmware is located) that are on the WAN port side of the router. Bear in mind that anything connected to one of the LAN ports on the router is considered to be part of your VPN, but sometimes you might wish to access a machine or device (such as an “upstream” router) on the WAN side of the router with the Tomato firmware. To do this, you need to add the route to the WAN side network in the server configuration (in the “up” and “down-pre” script sections at the bottom of the Webmin server’s configuration page, using an additional “route add” and an additional “route delete” statement), and then on the client configuration page you must add an additional iroute statement – all of those take the same format as the lines you added to access the network on the LAN side of your client. At that point, you can access machines on the WAN port side of the Tomato router, but it’s not reciprocal – they can’t access machines on the server side.
Now, I need to make an important distinction here – I’m talking about machines connected to the WAN side of the Tomato-firmware router. Anything connected to one of that router’s LAN ports should already have full access to your network (on the server side). But the thing to remember is that ANY traffic sent out by a client connected to the LAN side will go through the tunnel. In some cases that may not be the desired behavior – you might have a few devices that should use the local Internet connection for all outgoing traffic (that is, as a rule they DON’T send their traffic through the tunnel), BUT you’d like to make an exception so that they can access only the local network on the server side of the tunnel, so that “local” traffic CAN be routed through the tunnel. So, you’d have such devices on the WAN port side of the Tomato-firmware router (that is, connected to the same “upstream” router or switch as the Tomato-firmware router) so they don’t use your tunnel for the bulk of their traffic.
So the question then becomes, is it possible to allow those devices to use your tunnel ONLY for traffic to the local network on the server side of your tunnel? Well, it is, but it’s a bit tricky to set up. Note that you MUST first have it working in the opposite direction (that is, at a machine connected to the server side of the network, you can reach machines on the WAN port side of your Tomato-firmware router – that’s what I was talking about a couple of paragraphs up). If you can’t do that, you’re not going to get it working in the opposite direction. If you CAN do that, then here are the additional steps:
In the Tomato-firmware router, click on “Advanced” (in the left-hand menu), then “Firewall”, then check the box next to “Respond to ICMP ping.” You should now be able to ping the Tomato-firmware router from another device on the WAN side of the network (which may be important for testing and troubleshooting).
Next, click on “Administration”, then “Scripts”, then click the “Firewall” tab. You should see a big text entry box with (probably) nothing in it. Enter lines similar to the following:
iptables -t nat -I PREROUTING -s 192.168.10.0/24 -d 192.168.0.0/24 -j ACCEPT
iptables -t filter -A wanin -s 192.168.10.0/24 -d 192.168.0.0/24 -j ACCEPT
iptables -t filter -A wanout -s 192.168.0.0/24 -d 192.168.10.0/24 -j ACCEPT
In this example, addresses on the WAN port side of the Tomato-firmware router are in the 192.168.10.x range, while addresses on the server-side LAN are in the 192.168.0.x range. If either is different on your system, be sure to change all three instances of the appropriate base address.
Then click the Save button at the bottom of the page. After that it should look like this:
Reboot the router (or you can ssh in and manually enter each of the lines from a command prompt, if you want to avoid the reboot). Now any traffic for the server-side LAN that reaches the Tomato-firmware router will get passed through the tunnel, but you still need to instruct the individual machines or devices to route that traffic correctly (which may be easier said than done for some machines). I don’t know how you do it from a Windows box, but I can tell you how it’s done on a temporary basis (that is, it survives until the next reboot) on a Linux-based or Mac OS X based machine. For the sake of these examples, assume the Tomato router is at (and can be pinged at) 192.168.10.50:
From a Linux box:
sudo route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.10.50 eth0
(eth0 is the name of the interface used to connect to your local network)
From a Mac OS X box:
At a terminal prompt enter:
sudo route add -net 192.168.0.0 -netmask 255.255.255.0 192.168.10.50
Then, if there are shares on server side of the network that you want to connect to, and you know the host machine’s IP address, open a Finder window, click on “Go” in the top menu bar, and enter this as the destination (substituting the correct IP address for the target machine):
smb://192.168.0.xx:139
Note that in at least some cases, the connect attempt will fail if you don’t explicitly specify the port (:139) – this is apparently some kind of bug in recent versions of OS X.
If anyone knows how this is done on a Windows box, or how to make these route statements persist after a reboot (remember, they must be run by the root user or a user with root-level privileges, which is why the sudo statement is used — and you can’t put sudo in a script because it prompts for a password), please leave a comment and share your knowledge!
If you have followed this series thus far, I should point out that these articles are not static – if I find a mistake, or a better way to do things, they may get changed. On the other hand, since this particular router probably won’t be in my possession much longer, it may be something that I don’t do much more work on.
One thing I had said I would do in this last article is to give you a list of links that I found useful, or at least interesting, while working on this project. I didn’t actually utilize the information in all of these, and some are even a bit off-topic for the subject at hand, but this is just a small fraction of the pages I went through while trying to get this to work:
The ‘Point and Click’ Home VPN HowTo Guide (this was one of my primary sources)
OpenVPN: Building and Integrating Virtual Private Networks (book – Amazon affiliate link)
Tomato’s Frequently Asked Questions & Tips
Tomato (firmware) page at Wikibooks
An Easy Guide to Installing Tomato on the Asus 520gu
Teddy_bear’s Tomato 1.25 ND USB + FTP/Samba Mod (In my opinion the best firmware mod for Asus WL-520GU – be sure to get the VPN version)
Keith Moyer/SgtPepperKSU’s VPN build with Web GUI (also a great version, particularly if your router isn’t supported by the above version)
His blog
thor2002ro’s SDHC | SNMP | VPN | USB Mod (includes features from both of the above versions plus some additional features, but note that latest versions won’t run on routers with insufficient memory).
Summary of OpenVPN settings in Tomato Firmware
Setting Up A Low Cost NAS Using Tomato
Did I configure QoS VoIP correctly? (message thread)
QOS for SOHO VOIP Solved, Tomato Firmware
Optware installation instructions (supposed to also work with Tomato firmware, potentially allows use of numerous software packages originally written or converted for Linksys NSLU2)
OpenVPN IPv6 Tunnel Broker Guide
OpenVPN client configuration for Windows, Linux, Mac OS X and Windows Mobile for Pocket PC
Installing a Virtual Private Network with OpenVPN
EDIT: Create a VPN with the Raspberry Pi
USB disc partitioning utilities available.
“A set of disk utilities that will execute on a Tomato router. With these utilities you can now create ext2 partitions on a USB drive on the router itself, so you don’t have to use a Linux desktop machine to do it anymore.”
“A brief help file is included.”
Download link (filename is “tomato_dskutils.tgz”)
Direct link
And there’s probably plenty of other great links that I’ve missed.
Finally, one more word about the TAP/TUN issue. I would sort have liked to have gotten this working in TAP mode. However when I tried to set it up, OpenVPN (on the server) complained about a missing brctl file. Well, it turned out that the way to get that file was to do yum install bridge-utils – sounds easy, right? I assure you, absolutely nothing about this project was easy, at least not for me.
The problem was that after I had installed the software and switched both sides from TUN to TAP, and then restarted the OpenVPN server, it brought down the entire local network! I mean to tell you, I couldn’t connect to any web pages or do anything else until I physically killed the power to the server box! When I brought it back up and disabled OpenVPN, everything connected to the LAN worked fine again. When I uninstalled bridge-utils and went back to using TUN, the tunnel started working again. I had been up all night, it was coming up on 7:00 AM, and I was just so doggone frustrated by that point that I never even tried to get TAP working again. Besides, I just don’t like doing things that can bring down the entire network. I suspect it was doing some kind of packet flood thing, sort of a denial-of-service attack on my local network – pardon me if I’m not thrilled about the prospect of trying that again!
After some additional online research, I suspect that part of the problem is that after installing bridge-utils, you need to create and/or modify certain files, such as /etc/sysconfig/network-scripts/ifcfg-br0, /etc/sysconfig/network-scripts/ifcfg-eth0, and possibly /etc/sysconfig/network-scripts/ifcfg-eth1 (though I’m not at all sure about that last one). For example, one site I went to (which, for some reason, I could only read by using Google’s cached copy, which is why I’m not giving a link) said, “Configure this server’s network configuration to use a bridge as its primary interface. You do this by bridging the physical ethX and virtual tapX interfaces into one logical br0 interface. The br0 interface will be assigned an IP address, and not the physical or virtual interfaces.” That site also suggests that those files should read as follows (note that I do not recommend following this advice verbatim, see my comments below):
/etc/sysconfig/network-scripts/ifcfg-br0
DEVICE=br0
TYPE=Bridge
IPADDR=192.168.0.50 <— local IP of the server
NETMASK=255.255.255.0
ONBOOT=yes
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes
/etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=tap0
TYPE=ETHER
BRIDGE=br0
ONBOOT=yes
Please note the above is totally untested at this point, and I’m afraid that the advice to modify the existing files (particularly /etc/sysconfig/network-scripts/ifcfg-eth0) may (or may not) be ill-advised. What concerns me is that the /etc/sysconfig/network-scripts/ifcfg-eth0 file seems to contain a lot of essential information that is in effect being thrown out – for example, on our system, it reads as follows:
DEVICE=eth0
BOOTPROTO=static
DHCPCLASS=
HWADDR=00:xx:xx:xx:xx:xx
ONBOOT=yes
TYPE=Ethernet <— NOTE!! 'Ethernet', not 'ETHER'
IPADDR=192.168.0.50
NETMASK=255.255.255.0
BROADCAST=192.168.0.255
NETWORK=192.168.0.0
NOZEROCONF=yes
I’m just not sure what is the proper thing to do here — maybe just add the BRIDGE=br0 line to the existing file? But, if you do decide to try a full replacement of any file, be sure to copy the existing file to a safe location so that if things go badly you can recover your original file!
Some of the comments I have read suggest that TAP mode is not as efficient in transferring data, and/or not as secure (unless you add even more configuration options), so I’m thinking maybe we should leave well enough alone. But, if you have a truly burning desire to get it going, I suggest using the following Google search string for additional information – it may be strange, but it actually produced the most relevant results of all the searches I’ve tried over the last few days:
“/etc/sysconfig/network-scripts/ifcfg-br0” OpenVPN
Hopefully this page won’t show up as the first result! 🙂
If you have any ideas about what went wrong, or in particular, if you manage to get this working in TAP mode, I’d be most interested to hear about it (and how you did it, if you got it working) – the comments are open.
EDIT (November 30, 2011): While I’m not really wanting to reopen this project at this late date (this still remains about the hardest thing I’ve ever tried to do with a computer, and I have a distinct aversion to revisiting it), I did receive an e-mail today from James R, which I will post verbatim here. NOTE THAT THIS IS NOT TESTED BY ME, SO USE AT YOUR OWN RISK:
From: James R (address redacted)
Subject: OpenVPN in bridged mode
Date: November 30, 2011 11:32:40 AM EST
The following is a script to fix the problems with getting bridged mode OpenVPN working with PBX in a Flash (CentOS 5.7 with Webmin). First you install the third party Webmin OpenVPN module, then use the script below. I haven’t tested it yet, but I believe it should work if not explain what actions needed to be done to repair it. Be kind, as my scripting skills are quite poor.
#! /bin/bash
wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.2-2.el5.rf.i386.rpm
sleep 30
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
sleep 1
rpm -K rpmforge-release-0.5.2-2.el5.rf.*.rpm
sleep 1
rpm -i rpmforge-release-0.5.2-2.el5.rf.*.rpm
sleep 1
yum -y install bridge-utils
sleep 30
yum -y install tunctl
sleep 30
yum -y install openvpn
sleep 60
echo "start_cmd=/etc/init.d/openvpn start
openvpn_pid_path=/var/run
openvpn_servers_subdir=servers
zip_cmd=/usr/bin/zip
stop_cmd=/etc/init.d/openvpn stop
openvpn_path=/usr/sbin/openvpn
openvpn_clients_subdir=clients
log_lines=200
openvpn_version=2.0_rc16
openvpn_keys_subdir=keys
openvpn_home=/etc/openvpn
openssl_version=0.9.7e
openssl_path=/usr/bin/openssl
openssl_home=/etc/openvpn/openvpn-ssl.cnf
down_root_plugin=/usr/share/openvpn/plugin/lib/openvpn-down-root.so
br_end_cmd=/usr/libexec/webmin/openvpn/br_scripts/bridge_end
br_start_cmd=/usr/libexec/webmin/openvpn/br_scripts/bridge_start
tail_cmd=
log_refresh=
default_server=
" > /etc/webmin/openvpn/config
cat /usr/libexec/webmin/openvpn/br_scripts/bridge_start | sed
'2iPATH=$PATH:/sbin:/usr/sbin' >
/usr/libexec/webmin/openvpn/br_scripts/bridge_start
cat /usr/libexec/webmin/openvpn/br_scripts/bridge_end | sed
'2iPATH=$PATH:/sbin:/usr/sbin' >
/usr/libexec/webmin/openvpn/br_scripts/bridge_end
(End of James R’s e-mail. I fixed some punctuation and capitalization in the first paragraph, but otherwise it’s the way he sent it. I was NOT sure if the final couple of sections were really supposed to be three lines each, or one line each that got broken up by the e-mail software. I suspect the latter, but I’m leaving them as is in case I’m wrong about that. Again, please remember that the above is UNTESTED by me.)
Here’s another bit of information that may be useful for those of you that don’t know much about Linux — here is a very small list of Linux commands that may be useful in diagnosing any problems with your VPN tunnel:
Note that there are additional options for most or all of the above commands – read the man page for that command (e.g. man tcpdump) if you are interested, or use a search engine to find more information (yeah, I think most man pages are painful, too). man is short for manual, by the way, not a reference to gender.
Anyway, I’m still trying to catch up on lost sleep, but if I think of anything else pertinent I’ll probably add it to this article, rather than making this series any longer. I hope if you attempt this, it’s not nearly as painful for you as it was for me!
Continued from Part 2…
Okay, time for the hard part… well, at least it was for me. Please understand, the instructions at The ‘Point and Click’ Home VPN HowTo Guide, combined with the knowledge I acquired from the book OpenVPN: Building and Integrating Virtual Private Networks (Amazon affiliate link) by Markus Feilner, enabled me to get a tunnel going using a software client with no sweat. But getting it to work with the Tomato VPN client, and in particular, to get it to work the way we needed it to, was a whole other thing. It turned out, as so often happens that some simple configuration changes were all that was needed – but finding the correct configuration changes to make were pure grief.
EDIT: The above-mentioned book has been updated and expanded under a new title — see Mini-review of Beginning OpenVPN 2.0.9 by Markus Feilner and Norbert Graf (Packt Publishing)
I want to digress just a moment to speak about those elitists that seem to frequent certain forums and IRC channels, and just love to tell newbies (often in not so polite terms) that all the answers can be found by using Google. I’ve pretty much figured out that most of the time, the person saying that doesn’t know the answer either, but they are like the schoolyard bully that gets their kicks by picking on others. In this case, Google may have had the answers somewhere, but they sure weren’t showing up in the first few pages of results. Instead, what was showing up was many others who were having the same problems and asking the same questions, but not getting answers! And usually after the first four or five pages of results, the results became even less relevant, if that were possible. Finally, after taking a more or less scattershot approach to seeking help, I came up with a “recipe” that works in this situation. Of course I cannot guarantee it will work for you… heck, I can’t guarantee it will work for me next week… but at least it’s working as I write this. But the next time someone suggests that you should just Google it (or something like that), I suggest you ask them what search terms they would suggest using that will bring you the answer to your question. When whatever they suggest doesn’t work, let them know and ask for more suggestions, and just keep repeating until you find the answer or they get sick of talking to you. If we all did that, I suspect some of the online bullies would discover that maybe they should keep quiet if they don’t know the answer.
Okay, so to begin, let’s make sure we are all on the same page. I assume you’ve installed the Webmin OpenVPN + CA module (again, following the instructions at The ‘Point and Click’ Home VPN HowTo Guide) but if you had difficulty locating the module, try here — as I write this, it appears that the newest version of the module is the OpenVPNadmin WebMin pre-release 2.5 version. And when you try to download it, if you get “Unauthorized access to downloads!”, try a different browser, or make sure JavaScript and cookies are enabled. You will probably need to download it to your computer first, then upload it to Webmin, if your experience is anything like mine was.
When you go into the module, you’ll initially see a page like this:
This is “home base” for this module, so when I say “return to the admin page”, this is the page I mean. It’s also the page you use to create a new Certification Authority (normally you only need to do that once, but if you really want to you can make more). In the upper left corner there is a link labeled “Module Config” – click on it and make sure all the paths are correct:
A couple notes on this page: First, although it indicates that “Server Hint for Clients” is a required field, there is no indication of what actually goes there, nor any default value. Second, the information under “If you use bridge device” is only applicable if you use TAP mode (remember, we’re using TUN), but I do know the defaults are not correct. Just in case you ever want to try to get TAP mode working, here is what these paths should be (at least on our installation):
Command to start Bridge:
/usr/libexec/webmin/openvpn/br_scripts/bridge_start
Command to stop Bridge:
/usr/libexec/webmin/openvpn/br_scripts/bridge_end
Path to DOWN-ROOT-PLUGIN:
/usr/share/openvpn/plugin/lib/openvpn-down-root.so
Do check the paths on this page, because the defaults aren’t totally correct. Now let’s return to the admin page. I probably should have mentioned that you don’t really need to change any of the defaults for making a certificate for just your own use – those values are probably only important if you are creating a certificate that will be used by the public. Once you have made a certificate, you can click on the Certification Authority List, where you’ll see this page:
I really don’t know why you can create a new Certification Authority on both this page and the main admin page, but oh well… once you have created one it will show up in the list at the top of the page. You can click on it to view what you created, but there’s nothing you can change there. The main thing of importance is the “Keys List” link, where you can actually create new keys and view existing ones:
Okay, now here’s the important thing to remember about key creation: You need one key for your server, and one key for each client. You will note we have a server key, and client key for the software client (used for testing) and one more for the OpenVPN client on the Asus router.
As you may have surmised, except for the key name field, you can leave everything else at the defaults. However, there is one thing on this page that will lead you astray. It says, “Server key doesn’t need password!“, which might lead you to think that a client key does need one, but that’s not true. And if you use a password with your Tomato-based client key, you will never make a successful connection. The keys are far stronger protection than passwords anyway, so the only reason you might even consider using one is for a software client where you want to keep anyone other than an authorized user from connecting to the VPN tunnel. Anyway, don’t use a password for your server key or your Tomato OpenVPN client key!!!
Okay, now it’s time to navigate back to the admin page, then click on “VPN list”. Once you have created a server key, you can create your actual server. So click on the New VPN Server button and a page will come up that permits you to create a server configuration. This is where things get really tricky. Here is how ours is filled out:
Now the above is actually the edit page you get once the server is created and you have returned to edit it. Note that some values cannot be changed after the initial entry, so be sure you get them right the first time. In particular, make sure to select tun and not tap. If you do make a mistake, you can always delete the entire server configuration and start over, but that’s a bit of a pain. There are some differences in our configuration and the one at The ‘Point and Click’ Home VPN HowTo Guide, and generally speaking there are good reasons for the differences. But that said, nobody is claiming our configuration is perfect, just that it works! If you see something here you think should be changed, feel free to leave a comment.
Note in particular the text fields at the bottom of the page. Getting those right is the key to making this thing work! So, here’s what’s in each of those:
Additional Configurations:
push “route 192.168.0.0 255.255.255.0”
push redirect-gateway
push “dhcp-option WINS 192.168.0.50”
script-security 2 system
up (script execute after VPN up):
route add -net 192.168.5.0 netmask 255.255.255.0 gw 10.8.0.2 tun0
echo 1 > /proc/sys/net/ipv4/conf/tun0/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp
down-pre (script execute before VPN down):
route delete -net 192.168.5.0 netmask 255.255.255.0 gw 10.8.0.2 tun0
Of course, in the Additional Configurations section you want the line push “dhcp-option WINS 192.168.0.50” to point to a WINS server on your network, if you have one (if you don’t, just leave that line out).
In the up and down-pre scripts, if you want to be able to reach the local network behind the WAN port of the router on the client side, you should add additional route add and route delete lines in a format similar to those above, but substituting that network’s address range.
Now, once again, I’m NOT saying this is a perfect configuration, just that it works for us. However, if you notice something that just doesn’t look right, feel free to leave a comment. Much of the added configuration was put in so that traffic from the primary LAN to addresses in the 192.168.5.x address space would actually go through the tunnel – that was the hardest part. It was (relatively) easy to create a tunnel in the first place, but getting packets to and from their intended destinations was another matter entirely.
When you have configured your server and clicked “Save”, it should show up in your server list:
Now click on “Clients List” – there will be a button labeled “New VPN Client” (no screenshot, it’s just a button to click at this point). Click that button and you will be presented with a client configuration page. Here’s the one we created for our Tomato OpenVPN client running on the Asus router (again, this is actually the edit page, since the client is already created on our system):
Most of the settings here will be the defaults but there are two things to pay particular attention to: First, the “Remote IP” must be the external address of your server – remember that this is the configuration that goes to the client. And second, notice the ccd file content box at the bottom – it is crucial that this be filled in correctly. In our case, we used this line:
iroute 192.168.5.0 255.255.255.0
If you miss this – and I speak from experience on this one – the packets from the Internet or your local LAN just aren’t going to get back to the client end of the tunnel! And remember to add an additional, similar line if you also want to be able to reach the network connected to the WAN port at the client router, substituting the base address of that network for the 192.168.5.0.
Once you have saved this, it should appear in the VPN client list:
Once you have configured a client, the next step is to export its configuration, particularly the certificate and key files, to your computer using the “Export” link – all the necessary files will be packed up in a ZIP file. The instructions at The ‘Point and Click’ Home VPN HowTo Guide tell you how to use this file with a software client, but with your Tomato firmware you will have to unzip the file and then open each of the three files (ca.crt, plus the client certificate and key files), in a text editor or viewer. Only those three files are used with the Tomato OpenVPN client; the others in the ZIP archive are not. Then you will need to cut and paste the contents of those files into the three fields that appear under VPN Tunneling | Client | Keys tab in the Tomato firmware (see the screenshot of that page in Part 1 if you’re not sure what file’s contents goes where). With regard to the Client Certificate, there is some extra information at the top of the file that does not need to be pasted into the text field – you only need the two lines —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—– plus all the lines in between those two tags. On an Asus WL-520GU router it doesn’t matter much, but there have been cases with some other makes of router where leaving that excess information in was just enough excess data to “brick” the router! So if in doubt, leave the data above the —–BEGIN CERTIFICATE—– line out.
Once you have everything ready, you can go to the OpenVPN admin page in Webmin and start the server, then in your Tomato firmware start the client. HOPEFULLY the client and server will connect and start communicating. You can check from the server’s admin page by clicking on “Active Connection” – hopefully you will see something like this:
If you do, congratulations! If not, you have some troubleshooting to do. On the server, take a look at the log file: /etc/openvpn/servers/servername/logs/openvpn.log. On the client, click on Logs (under Status in the left-hand menu) and look at the last several lines. OpenVPN usually doesn’t suffer in silence — when something isn’t working, chances are one or both logs will be filled with messages that may or may not be helpful. You can always try going to Google and using OpenVPN plus the actual error message text (enclosed in quotation marks); once in a while that will actually bring up something useful.
Still stuck? My plan is to add a Part 4 to this series, that will provide links to some of the most useful resources I’ve collected along this journey. But you can certainly help — if I’ve made any errors in these instructions (not at all unlikely given the sleep I’ve missed during this project), and you find them and can figure out what was incorrect, PLEASE leave a comment. I will warn you that writing to me with your error message will probably get you nowhere – I can definitely play the part of the blind leading the blind, so to speak, but first I have to heal from all the bruises encountered on this journey! 🙂
I sincerely hope these posts have been useful to you! In Part 4 I’ll wrap this up with brief instructions for rotating the log file so it doesn’t grow forever, provide the aforementioned list of links, and give you a bit more insight into why I set this up using TUN mode even though I’d probably have preferred to use TAP.
Recent Comments