Samba WINS Support
In order to use Windows filesharing across different subnets, you need a WINS server to allow resolution of computers' NetBIOS names across subnets. Luckily, Samba has that capability built in and enabling it is as easy as adding:
wins support = yes
To Samba's configuration file, smb.conf, and restarting the Samba server. In Windows networks, all the computers participate in an election process to determine the computer that will be the local Browse Master. The Browse Master is responsible for collecting and distributing all the information regarding Windows shares within its subnet.
That information is then transmitted to the domain Browse Master to distribute across subnets. Generally, we'd like the WINS server to be the domain master, so we set this by "rigging" the election with the following:
local master = yes os level = 35 domain master = yes preferred master = yes
You need only one SMB server running the WINS service for all your subnets. For simplicity's sake, I like to put it on the same machine that is acting as the OpenVPN server. You can also enable a Windows-based WINS server instead of using Samba.
As you might expect, encryption takes its toll on network performance. But, in practice, network throughput will be limited more by the Internet connections of both the OpenVPN server and client, than by OpenVPN itself. For my setup, I get speeds of around 35 kbps, but the client side of my network uses a wireless point-to-point Internet provider that sounds good on paper, but in reality, is horribly unreliable.
To get a better look at OpenVPN's true performance, I set up both the server and client locally connected through a gigabit switch and transfered some files through them over SMB. Direct transfer (without OpenVPN) clocked in at around 38 Mbps. The same transfer over an encrypted tunnel was barely able to top 4 Mbps. But again, unless you have top-tier fiber-based connections on both ends of your encrypted tunnel, you're unlikely to be limited by OpenVPN itself.
So you definitely pay the price on the performance side, but you gain the ability to securely transfer data over insecure connections.
If you don't want to dedicate a computer at each end of an OpenVPN tunnel, there are implementations of OpenVPN that run on the limited hardware of consumer grade routers (like the Linksys WRT54G) through DD-WRT or OpenWrt. So don't worry about old hardware slowing you down!
There are quite a few pieces that have to play nicely together to get OpenVPN working correctly. Here are a few tools that come in handy if things don't work smoothly right out of the gates.
- Check the OpenVPN logs There is lots of good information in there that can point you right to the problem. This is especially handy when tweaking the config files.
- Increase the verbosity This will show you more of what OpenVPN is thinking. A verbosity level of 5 or 6 is pretty handy for high level checking, anything higher is great for really tracking where packets are going.
- Use "tcpdump" tcpdump is a great network troubleshooting tool, especially since both OpenVPN machines are acting as routers. Check the tcpdump man page for more details.
- Take baby steps! Build up the VPN incrementally and test the connection along the way. (i.e. bring up the tunnel, make sure your can ping through the tunnel, then try with other machines on the network)
VPN's can be handy for a myriad of setups, connecting remote laptops back to a main office's servers or even connecting whole networks together securely over the Internet. OpenVPN offers an "industrial-strength" VPN suite that's both versatile and powerful. It has a great reputation and is a snap to set up.