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:
Webmin Log File Rotation - Add New File page
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.
Deny and Permit fields from FreePBX extension page
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)
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
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.
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:
- ifconfig – shows the current list of network interfaces. On both ends of your tunnel you should see a tunx interface when the tunnel is operational. On Windows-based systems a similar command is ipconfig.
- ip route show – shows current routing information for the system (see also route). ip route list gives a slightly different view.
- iptables -L – lists the current iptables rules. Add the -v option to get a more verbose display.
- netstat -r – similar to route but with a slightly different view.
- ping address - tries to get a response from another connected machine or device. Note that not all systems or devices will respond to pings.
- route - shows the current routing tables on the system (see also ip route show).
- tcpdump -n – this shows a running display of all activity on the network interfaces. Be careful because this can produce a LOT of output very quickly. Use Control-C to interrupt, then be prepared to wait until the buffer empties (may take a few seconds.
- traceroute address – If you run a traceroute to a network address (either on the LAN or on the Internet) it will attempt to show each system the packets pass through on the way to their destination. This can be useful for determining if traffic to a particular destination is actually going through your tunnel. On Windows-based systems use tracert (a holdover from MS-DOS days when filenames were limited to eight characters!).
- which program-name – not a network command per se, but if you get an error message about a missing program, you can use which program-name to try to determine if the program exists on your system, and the correct path to that program.
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!
Subscribe to Michigan Telephone, VoIP and Broadband blog
