Vpnc Ipsec

• Vpnc Ipsec Site
• Vpn Ipsec Nat

The VPN has revolutionized the way we work. For over 20 years it’s allowed everyone from executives on down a company’s organizational chart to work anywhere, from home to the airport to the resort. (The debate of work/life balance versus always available connectivity will not be solved by me and not here.) This ability to connect almost anywhere in the world has not only revolutionized how we work, but it has saved many on-call engineers late-night trips to the datacenter.

Otherwise, if your vpnc process is going down, it may be because the VPN endpoint is overloaded, either endpoint is sending packets that the other endpoint believes to be invalid and so has torn it down, or vpnc is ostensibly broken. See if anythin is mentioned in its associated log files. Sudo apt-get install network-manager-vpnc. Sudo apt-get install network-manager-openvpn. Not covered on this page, so far. Click on the network-manager in the system tray; Choose VPN Connections - Configure VPN.

IPSec gateway gateway.example.com Starting. The vpnc package comes with a systemd unit vpnc@.service. If you want to use the configuration file /etc/vpnc/client.conf, you would start it with systemctl start vpnc@client. In case the vpnc client crashes with. Vpnc will look for the files /etc/vpnc.conf or /etc/vpnc/default.conf.If it does not find such files, vpnc will default to the interactive mode. However, vpnc can support different configuration files and be called with the name of the file as an argument.

However, in spite its convenience and functionality, the VPN can present significant security risks if it is not properly implemented.

First and foremost: which VPN protocol are you using? Many VPN protocols and encryption algorithms have come and gone, like PPTP, modem banks, DES and so on. In today’s world there are two heavyweights in the realm of maximum security, support and functionality: IPsec and SSL.

IPsec VPN

IPsec has been around for decades and is the tried-and-true solution. As time goes on, IPsec adapts by adding supported encryption and hash algorithms, like DES, which gave way to 3DES, which gave way to AES and so on.

Every IPsec VPN connection goes through two phases. During phase one of the connection, the VPN peer devices negotiate how the are going to encrypt and pass traffic. If you must use the Internet Key Exchange (IKEv1) protocol here, there are a couple of important things to remember. The obvious things are encryption/hash algorithm and the length and complexity of the pre-shared key. The most important aspect of IKE is whether you are using Aggressive Mode vs. Main Mode. Essentially, aggressive allows for the two VPN peers to run through sort of a trial and error for the initial exchange of the pre-shared key.

This presents a huge security risk that can allow an attacker to crack the pre-shared key. Here’s a really good write up of that information.

Once you are in phase two of the IPsec process enable perfect forward secrecy (PFS) and Replay Detection to protect the tunnel once it is established.

SSL VPN

The new hotness in terms of VPN is secure socket layer (SSL). You can use an SSL VPN to securely connect via a remote access tunnel, a layer 7 connection to a specific application. SSL is typically much more versatile than IPsec, but with that versatility comes additional risk. The biggest mistake I see in the field regarding SSL VPNs is using untrusted, self-signed certificates and not keeping up to date on patches for your VPN endpoint device. The list of SSL vulnerabilities is pretty long, with the most famous recent one is the Heartbleed vulnerability.

Additional Security Considerations

For both SSL and IPsec VPNs, you will always have to worry about authentication and access. If you’re a smaller environment, you can use local authentication on the firewall. Most environments will leverage Active Directory as the authentication source for the VPN using either RADIUS or LDAP. Both protocol options are relatively easy to set up and it’s easy to forget to use the secure options for both.

Once connected, a VPN client has access to the business network. In the world of BYOD, the end user’s computer connected to your network is the biggest vulnerability. Your network administrators have no control over personal devices and their compliance. Fortinet, Cisco and other vendors have product offerings to perform network access control (NAC). NAC allows the firewall to check a client system for patch level, antivirus and other measures of compliance. Non-compliant systems are either not allowed to connect or isolated.

If you have questions about your VPNs or additional security layers to help protect your environment, send us an email or give us a call at 502-240-0404 to get started!

This document details how to connect a workstation to a Cisco VPN concentrator utilizing vpnc to manage the connection.

Introduction

This document is meant for users who want to connect to their office network from home or during travel. Many companies utilize Cisco 3000 VPN concentrators for their VPN needs, and I am willing to bet that most Linux newbies think that they are forced to use Windows to connect to them. Well, this document explains that connecting to a Cisco VPN is definitely possible and will hopefully enable to setup a working tunnel using a Gentoo workstation or laptop.

What this document is

• A guide to the basic workings of vpnc
• A discussion of DNS and routing issues that relate to VPNs
• Examples of managing VPN sessions
• Useful tips and tricks (hopefully)

What this document is not

• An in-depth guide to VPN/encryption technologies
• A feature by feature explanation of vpnc

Assumptions

The assumptions made at this point are:

• Gentoo is installed
• Internet access is available and configured
• The connection is towards a Cisco 3000 VPN concentrator
• Configuring, building, and installing a new kernel is not a daunting task for the reader

Installation

Kernel

In order for Linux to be able to open a VPN connection Universal TUN/TAP device driver support must be enabled in the kernel. What is it and why is it needed? Below is a relatively straight forward explanation from the kernel configuration dialog:

To verify that the kernel has TUN/TAP support, grep the kernel's configuration file:

As can be seen above, CONFIG_TUN=m is compiled as a module. If it is disabled in the setup, enable it in the kernel of choice, rebuild, install, reboot and return to this document before continuing with the next steps.

If TUN/TAP support is built directly into the kernel, dmesg output should look like the following:

If TUN/TAP support is built as a module, then first load the tun module:

Now that the tun module is loaded, check dmesg output. Something like the following should show up:

Emerge

Now that a working kernel setup is completed, install the net-misc/vpnc package:

Make sure to check the supported USE flag combinations and see if they apply to the environment. When encountering a problem later with the following error, enable the hybrid-auth USE flag:

Configuration

In order to make the following sections more clear, we need an example setup to work from. For the purpose of this exercise, we will assume that the home network consists out of several computers. All computers are on the 192.168.0.0 / 255.255.255.0 network. The LAN in question is run by a Gentoo box using an iptables firewall, DHCP, caching DNS, etc ... and it masquerades the LAN behind the public IP address it receives from an ISP. A workstation is also on the LAN from which the VPN into the office will be configured.

Our example workstation configuration looks like the following:

vpnc

Now that vpnc is installed and we have an example to work from, let's discuss the basics of setting up vpnc. The configuration file for vpnc connection settings can be located in a couple places, depending on how many profiles need to be configured. By default, vpnc looks for /etc/vpnc/vpnc.conf for its connection settings. This setup will only address a single profile example and will use the configuration file location /etc/vpnc/vpnc.conf .

The configuration file example above should be modified to reflect the appropriate values for the local setup. The gateway option vpngateway.domain.org can be a fully qualified domain name or an IP address. The ID and secret options should be given by a network administrator. If this information cannot be obtained but a working setup on a Windows box is available which utilizes the official Cisco VPN client, then it suffices to export the profile. The user name and password options are for the normal network sign-on, such as a Windows NT domain account.

When the profile is exported from a Windows machine, then the result is most likely a file ending in .pcf . This file will have all the necessary information. Below is an example:

In the above example, we can see entries for Host, GroupName, and enc_GroupPwd. The Username and UserPassword may or may not be exported depending on the setup. To generate a working vpnc configuration out of it, use pcf2vpnc, included with vpnc.

Testing the setup

Now that a configuration is in place it is time to test the setup. To start vpnc do the following:

The above command output shows that, once vpnc (as root) is executed, a prompt comes up asking for a password. After entering the password (which will not be echoed to the terminal), the vpnc process will automatically become a background process.

As can be seen from the above command output(s), vpnc has done the following:

• Created the tun0 network interface, a virtual interface to handle the traffic across the VPN tunnel
• Obtained the IP address for the tun0 device from the VPN provider
• Set the default route to the VPN gateway

At this point, the workstation is capable of communicating with hosts via the VPN. Because vpnc sets the default route to the VPN gateway, all network traffic will travel across the VPN, even if it destined for the Internet or elsewhere not specifically specified by additional routes. For some, this basic type of connection may be satisfactory, but for most, additional steps need to be taken.

Additional things that might be interesting to have:

• DNS for the VPN
• A routing setup that will only send traffic destined for the VPN down the virtual tunnel. This way, browsing the Internet will originate directly from the local network even when connected to the VPN, without the personal web/p2p etc. traffic going across the tunnel.
• A script to manage all this, because vpnc just doesn't do enough by default.

To end the VPN session, execute vpnc-disconnect. An example is shown below.

Set up DNS

Unfortunately, vpnc doesn't handle the setup and management of DNS for the newly established tunnel. The user is left to decide how DNS should be handled. Although /etc/resolv.conf can be written during the connection, that would utilize the VPN DNS for all DNS queries regardless of whether or not the traffic is destined for the VPN tunnel. This is a very functional solution and if all that is needed is to connect to the tunnel, work, and then disconnect, read no further. But, to be able to leave the tunnel connected for lengthy periods of time without the work DNS servers handling requests for the personal traffic, read on.

The ideal setup would allow users to separate the DNS queries into two categories: VPN-related and other. Under this setup, all VPN-related DNS queries would be answered by DNS servers located at the other end of the VPN tunnel and all other queries would continue to be answered by local or ISP supplied DNS servers. This is the setup that will be demonstrated here.

So how to make sure that requests made to hosts on the example.org domain get sent to VPN supplied DNS servers? Well, first install a local DNS server, but don't worry, it's much easier than it sounds. There are several software packages that can handle the type of setup we desire, but for the purposes of this demonstration, dnsmasq will be utilized. Let's emerge it now:

Next add an option to dnsmasq's startup options. Edit the following option and substitute .example.org with the appropriate domain and the IP address with a valid DNS server that belongs to the VPN tunnel.

Next, make sure that the first entry in /etc/resolv.conf is the local host 127.0.0.1, followed by the location of the backup DNS servers that should handle the DNS traffic in case dnsmasq fails to start, or if it needs to forward a DNS query it doesn't currently have in its cache. An example /etc/resolv.conf is shown below.

Now that a rule is setup for the VPN tunnel DNS, start dnsmasq.

The routing table

The ideal scenario would be if only the traffic destined for the VPN tunnel would travel across the link. At this point, a VPN tunnel setup exists and all traffic will travel across the tunnel, unless additional routes are specified. In order to fix this situation, know what networks are available on the VPN. The easiest way to find out the needed information is to ask a network administrator, but sometimes they are reluctant to answer such questions. If the local network admin doesn't provide the needed information, some trial and error experiments will be required.

When the VPN tunnel was started, vpnc set the default route to the tunnel. So set the default route back to normal, so that things work as expected.

Earlier, when DNS services were being configured for the VPN, a DNS server was specified to handle the example.org domain. Add a route for the 192.168.125.0 subnet so that DNS queries will work:

At this point, any additional routes for known networks (such as for the subnet 192.168.160.0, which includes the IP address received by the TUN/TAP virtual device) should be added. If a friendly network administrator gave the required info, great. Otherwise, start pinging hosts that will be connected to frequently, to give an idea about what the routing table should look like.

As seen from the above example, the ping probes to intranet1.example.org were unsuccessful. So we need to add a route for that subnet.

A few ping and route commands later, and the system should be well on its way to a well working routing table.

Manage the connection

Calling vpnc when needed

Next is an example script to manage the VPN connection. Execute it (as root) from an xterm to start a connection to the VPN. Then all that is left to do is to press return to disconnect the VPN. Obviously this needs to be modified on the current setup, remembering to add all the additional routes that may be necessary.

Start vpnc on boot

Version 0.4.0-r1 of vpnc contains an init script (/etc/init.d/vpnc) which can handle multiple configurations. The default script looks for /etc/vpnc/vpnc.conf, but as many configurations as can be imagined are possible. Before and after shutdown and start-up custom-made scripts can be executed that are connected by their name to the corresponding init script (since version 0.5.1-r1). Their names end in -preup.sh, -postup.sh, -predown.sh and -postdown.sh, stored in the /etc/init.d/scripts.d/ directory. The general naming scheme is sketched in the following table.

Add vpnc to default runlevel with the following commands (in this case for the standard configuration). Do not forget to add the tun module (if built that way) to the kernel's autoload mechanism at startup.

To not have to save the password in the configuration file, tell the init script to show all output and prompts on standard output by editing /etc/conf.d/vpnc. Set the VPNCOUTPUT variable to yes or no, where its default is to not display screen output.

Tips and tricks

Graphical remote access

When looking for a Linux application that supports RDP (Remote Desktop Protocol) then give net-misc/grdesktop a try. It is a GUI app written in GTK that fits in well with a Gnome desktop, but doesn't require it. As an alternative to the GUI configuration dialog that grdesktop provides, just install net-misc/rdesktop. Ultimately, grdesktop is just a frontend for rdesktop.

KDE users might want to try out net-misc/kvpnc. It appears to be a very mature VPN management GUI.

To connect to a Windows machine which doesn't have a DNS entry, but for which the address of an available WINS server is known, use a tool called nmblookup to query the WINS server for the host name of the machine to connect to. Unfortunately, net-fs/samba needs to be installed to get it, but when working with boxes running Windows installing samba is usually a given, because it includes several other useful tools.

When samba and its tools are installed, test nmblookup by asking the WINS server at IP address 192.168.125.11 about a host named wintelbox1.

Vpnc Ipsec Site

Custom scripts on boot

The custom-made scripts for the init.d file can be used to setup a user-defined routing for the vpnc connection. The examples below show how to setup the routing table so that only connections to 123.234.x.x are routed over the VPN and all other connections use the default gateway. The example uses work-preup.sh to save the current default gateway before starting vpnc (which resets the default gateway using the VPN connection). Once vpnc has been started, work-postup.sh deletes this new default gateway, restores the old default gateway and sets the route for all connections to 123.234.x.x to use the vpnc connection.

The example scripts assume that the vpnc connection uses tun1 as tun device. Set the device name in the connection's configuration file.

Vpn Ipsec Nat

External resources

This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: David H. Askew, Christian Faulhammer, Thomas Fischer, nightmorph
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.