I tried to install the OpenVPN 2.0.9 client on Vista x64, but I wasn’t able to get it running. The installation procedure already complained that there are compatibility issues with the TAP driver (bridged tunneling). I also had a few issues on Vista x86, not with the driver, but with routing commands. Because I read that OpenVPN 2.1 has better Vista support, in particular for 64-bit, I didn’t bother with those problems for too long, but installed OpenVPN 2.1_rc15 instead.

I recommend you turn off digital driver signing on Vista x64 before you install OpenVPN. For this you have to press F8 when Vista boots up and then select the corresponding option. I also disabled UAC during installation, just to make sure that the setup always has administrator privileges. It appears that OpenVPN doesn’t like UAC. You can’t really blame OpenVPN for that because it has to change Vista’s routing table, for which it needs administrator privileges. To automatically start the OpenVPN client always with administrator rights, you can just configure its shortcut accordingly (see screenshot). If the UAC prompt whenever you launch OpenVPN gets on your nerves, I recommend using Symantec UAC.

On the server side, I installed OpenVPN on SuSE Linux 10.1. With the help of yast, it was easier than installing the client on Windows. To configure OpenVPN one has to create the file named net.conf under /etc/openvpn. I had a very simple setting for my test environment. This is what my configuration file looks like:

dev tun ifconfig 10.1.0.1 10.1.0.2 secret net.static.key

The “dev tun” command tells OpenVPN to encapsulate IPv4 or IPv6; i.e., it will establish a routed VPN. OpenVPN also supports bridged VPNs, which means that you don’t have to bother with routing configurations, but Ethernet bridging costs performance.

“10.1.0.1” in the ifconfig command is the end point IP of my server, and “10.1.0.2” is the end point IP of my client. The secret command refers to the secret key that I created with “openvpn —genkey net.static.key” on the server. This key has to be copied to the config folder of OpenVPN on the Windows client. OpenVPn also supports Public Key Infrastructure (PKI) for authentication purposes, but that would have been overkill for my purpose.

The configuration file (net.ovpn in the config folder) on the Windows client is quite simple too:

remote host dev tun secret net.static.key ifconfig 10.1.0.2 10.1.0.1 dhcp-option DNS 10.1.0.1 redirect-gateway def1

“host” has to be replaced with the public IP of the VPN server. You know “dev tun” and “secret” commands already. The ifconfig command has swapped IP addresses, because the local end point is now on the client and the remote endpoint is on the server.

I used the dhcp-option DNS command because I wanted my client to use the DNS server on my VPN server. This DNS server tells my Vista client to use the private IP of the server instead of the public IP for certain Internet domains. This makes sure that this communication is encrypted, too. The redirect-gateway def1 command changes the routing table on the client to redirect all Internet traffic through the VPN server.

OpenVPN has no NATing capabilities, which means that you have to use the server OS for this. On my Linux box I used iptables:

iptables -A FORWARD -i tun0 -o eth0 -s 10.1.0.0/24 -m state —state NEW -j ACCEPT iptables -A FORWARD -m state —state ESTABLISHED,RELATED -j ACCEPT iptables -A POSTROUTING -t nat -j MASQUERADE

You can also easily configure Windows Server to act as a NAT router.

Once everything is configured you can start the OpenVPN gui and double click on its systray icon to establish the connection. I have been using OpenVPN 2.1 RC for several days and didn’t experience any problems.

My article is not a review of OpenVPN, which is a very complex VPN solution. I just wanted to give you a first idea about this great VPN solution. I have read before about OpenVPN, but I must admit that when I first tried it I was quite surprised at how powerful it is. You should have a look at its command documentation to get an idea about its capabilities. I also found the Howtos quite useful.

• Windows 7 DirectAccess – Experiences (19)
• Windows 7 DirectAccess – Features (20)
• Intelligent Application Gateway 2007 Service Pack 2 available (0)
• Poptop: Linux VPN server for Windows clients using PPTP (10)

DirectAccess has to be installed as a feature on Windows Server 2008 R2. I wonder why it is a feature and not a role, considering that it is recommended to use DirectAcess on a server that has no other function. I must admit, I still don’t understand the difference between server roles and features.

It is interesting to note that two network interfaces are required, which indicates that DirectAccess has firewall functionality. One network card is usually enough for VPN. DirectAccess also complained that I have no Public Key Infrastructure. After I installed the Certificate Server role on the same machine, the DirectAccess setup was satisfied. The setup wizard then let me configure the user groups that are allowed to use DirectAccess.

Next, I had to configure the external and the internal network interface. The external interface needs a public IP address. The setup program was smart enough to recognize that I was using a private IP. It surprised me a little that DirectAccess bothered about the IPv4 settings, anyway. DirectAccess requires IPv6, which probably is the main reason why it will take a while until corporations embrace this new feature. In the last two steps, one has to identify the infrastructure servers (DNS, domain controller) and the applications servers.

I then tried to figure out what has to be configured on the client side. I am not sure if the Windows 7 Beta1 already supports DirectAccess, because I didn’t find a corresponding feature or service. I also skimmed over the Group Policy settings but I didn’t find any hints there. Unfortunately, the links to the help files on my Windows Server 2008 R2 didn’t work and I also wasn’t able to find any technical manual about it on the web. Please let me know if you were able to get further with your testing of DirectAccess. I will probably try it again as soon as Windows 7 RC is out.

All in all, I think DirectAccess is a very interesting new feature. It might even replace VPN in the long run. I believe such technologies are directly aimed at Google Apps & Co. The biggest advantage of cloud apps is that they are location-independent. Considering that network bandwidth for mobile users is rapidly improving these days, it won’t take long until it doesn’t make a difference anymore if users work in the corporate intranet or in a home office. Admins can manage remote machines as if they were in the office next door or on a virtual desktop in the datacenter. A desktop will be just a desktop no matter where it is located, whether it is virtualized or not. With private cloud technologies and features such as DirectAcces, we can enjoy the advantages of scalability, fat clients, and mobility.

• FREE: PhoneFactor – Mobile phone based two-factor authentication (1)
• How to disable USB drive use in an Active Directory domain (2)
• Service Account best practices – Part 2: Least Privilege implementation (0)
• Four fast ways to improve security in SQL Server 2008 R2 (12)
• Managed Service Accounts in Windows Server 2008 R2 (7)

Requirements

• DirectAccess server must run on Windows Server 2008 R2
• DirectAccess client must run on Windows 7
• DirectAccess Server requires two network cards
• Active Directory
• IPv6
• PKI (Public Key Infrastructure)

Advantages of Direct Access

• User doesn’t have to establish the connection
• User doesn’t have to reconnect if the Internet connection breaks
• Group Policy settings get active before user logs on
• Users can log on to Active Directory, just like in the intranet
• Works together with NAP (Network Access Protection) and NAC (Network Access Control) solutions
• Communication to the corporate network is encrypted with IPsec

Two IPsec tunnels (and authentication methods)

• Only the machine certificate is used for authentication: The remote computer can only connect to the corporate DNS server, Group Policy, and to Active Directory in order to be able to log on
• The machine certificate and user credentials are used for authentication: Only then will DirectAccess grant access to other internal resources

Two connection methods

• Selected Server Access: IPsec connection through DirectAccess server to each application server; application servers have to run Windows Server 2008 R2 or Windows Server 2008 and must support IPv6 and IPsec
• Full Enterprise Network Access: IPsec connection to an IPsec gateway (can be the DirectAccess server); IPsec gateway forwards traffic to IPv4 application servers

Connection through the Internet

• If a native IPv6 network isn’t available, the client has to establish an IPv6 over IPv4 tunnel
• Tunnel protocols supported: Teredo, 6to4 or Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), IP-HTTPS (firewall friendly)
• By default, Internet traffic is not routed through DirectAccess server
• Administrators can configure Windows Firewall to route traffic for specific applications or subnets through the DirectAccess server

Also check out my article about the experiences I made with DirectAccess.

• FREE: PhoneFactor – Mobile phone based two-factor authentication (1)
• How to disable USB drive use in an Active Directory domain (2)
• Service Account best practices – Part 2: Least Privilege implementation (0)
• Four fast ways to improve security in SQL Server 2008 R2 (12)
• Managed Service Accounts in Windows Server 2008 R2 (7)

• How to configure TMG for SSL Client Certificate Authentication (0)
• Using TMG, one-time passwords and Kerberos Constrained Delegation (2)
• How to use Kerberos Constrained Delegation with Forefront TMG (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 2 (0)
• Secure your Exchange 2010 Server with Forefront TMG – Part 1 (0)

But let me say a word about security first. PPTP has many critics. Crypto experts have shown that it is possible to crack this protocol under certain circumstances, especially MSCHAPv2 which is used for authentication, has its weaknesses. MPPE (Microsoft Point-to-Point Encryption) “only” uses a 128-bit-key. However, I think for most scenarios PPTP is secure enough. If you want to hide your communication from curious system administrators, PPTP will do the job quite well, but if you think that the NSA or Mr. Super Hacker will be interested in your data, better use a more secure VPN protocol like IPSec. The disadvantage is that things will usually become more complicated.

Installing Poptop is not difficult, if you are a Linux admin. The documentation is a bit poor, though. I think most Linux distributions already come with the necessary packages. I installed it with YaST on a SuSE 9.0 machine. The name of the package is “pptpd”. If some other packages are missing, YaST will tell you which ones. I had a problem getting the pptpd service running in the beginning. After a while it turned out that my 2.4.29 kernel didn’t like Poptop, somehow. I tried several other kernel versions, and it always worked fine with them.

These are four configuration files:

• /etc/modules.conf
• /etc/pptpd.conf
• /etc/ppp/options.pptpd
• /etc/ppp/chap-secrets

If you have an older Linux distribution, check your modules.conf for these entries:

alias char-major-108 ppp_generic alias tty-ldisc-3 ppp_async alias tty-ldisc-14 ppp_synctty alias ppp-compress-18 ppp_mppe alias ppp-comress-21 bsd_comp alias ppp-compress-24 ppp_deflate alias ppp-compress-26 ppp_deflate

In pptpd.conf, I only uncommented the localip and the remoteip variables. I used private IPs for both variables. In options.pptpd, I enabled mppe-128. Most important is chap-secrets. Here you set the user name and the password. You can reduce the weakness of MSCHAPv2 by setting a strong password here. Use a random password, with a mixed of small and capital letters. Ten characters should be the minimum length. Don’t use a password which you can remember easily. It is safer to let your VPN client store a strong password, instead of entering a weak and an easy-to-remember password whenever you connect to the VPN Server.

Then I configured the firewall to allow the PPTP protocol. With iptables, it looks like this:

iptables -A INPUT -p tcp –dport 1723 -j ACCEPT iptables -A INPUT -p 47 -j ACCEPT iptables -A OUTPUT -p tcp –sport 1723 -j ACCEPT iptables -A OUTPUT -p 47 -j ACCEPT

If you want to work with NAT (Network Address Translation), you have to add these lines to your iptables shell script:

iptables -A FORWARD -i ppp0 -o eth0 -s 192.168.10.0/24 -m state –state NEW -j ACCEPT

iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

iptables -A POSTROUTING -t nat -j MASQUERADE

The IP range here is the one you configured in pptpd.conf. You also have to enable IP forwarding which is disabled by default. On a SuSE box the easiest way to do this is by using YaST. You’ll find it under network services/routing. If you don’t use SuSE please check out Marius’ post about IP Forwarding.

Then you have to setup the VPN client on your Windows machine. Please go to this site for more information. The default PPTP setting of Windows should work.

With this configuration, you can already access the internet thru your Linux server using NAT. To make sure that you always use the VPN connection to access applications on the server, you can change C:\WINDOWS\system32\drivers\etc\hosts. Add the IP address to hosts which you set before for localip in pptpd.conf for the domain names that you are hosting on your Linux server. You have to reboot after changing the hosts file.

This way, your communication with the Linux host will always be encrypted regardless what application you use to access it. If you ever forget to establish the VPN connection first, you even won’t be able to access the Linux machine.

• Kiwi CatTools – Back up and manage network configs (0)
• FREE: Zenmap: Windows GUI for nmap (0)
• FREE: SolarWinds Real-Time Bandwidth Monitor (0)
• Set up a 802.1x in a Active Directory domain – Part 2 (5)
• Set up an 802.1x Wi-Fi network in a Windows Active Directory domain – Part 1 (0)