Tips and Tricks: Using vpnc in Backtrack 5 to connect to Cisco VPNs

Spread the love

Every once in a while, I’m going to post something that I pick up along the way.  These will usually be for my own reference after I’ve pretty much broken my brain trying to get something to work and it finally *just did*.  Often, these will be amalgamations or clarifications of things I’ve found elsewhere and I will give credit as such.  I make no promises that it will work for you, but I will provide as much detail along the way as I can.  I don’t usually use GUI package managers, though, so you may have to get into some new territory on that part if you’re not used to the command line.

Platform: Backtrack 5R3 guest in VMWare Workstation 9.0 running on Windows 7 host (but should work in native Backtrack as well)
Software: vpnc
Unusual Aspects: RSA token authentication

Part of my job in pen testing involves connecting to VPNs to perform tests on internal networks without having to physically visit the site.  This creates problems, though, as I usually run Backtrack from a VM, and either VMWare or Windows 7 (or both) are giving me troubles where sometimes the network simply stops functioning.  It’s an odd thing where at one point the NAT gateway is responding to ARP requests but then it’s not.  Nessus (running in Backtrack) keeps sending packets as seen in a capture in BT, but they’re not getting passed on through the host.  The issue isn’t present when running in bridged mode, but that means I can’t use the corporate VPN software on the Windows host.  But with the help of vpnc and a few sites on the Internet, I was able to get it working, which also allows me to run internal and external tests at the same time.

Part 1: Obtain necessary software

From a command line, run the following to install vpnc:

apt-get update
apt-get install vpnc

Also from a command line, run the following to set up your VPN work location:

mkdir ~/vpnconfig
cd ~/vpnconfig

Once you’ve completed this, you have the software you need and the necessary location to work with your profiles.

Part 2: Convert PCF file

Copy the PCF file to ~/vpnconfig (the leading tilde, or “~”, references the home directory of the logged-in user, so that’s the vpnconfig directory in your own home directory).  Once there, go back to the command line and run the following command:

pcf2vpnc <filename.pcf>

Of course, replace <filename.pcf> with the name of the file you need to convert.  You should see something like this:

Can't exec "cisco-decrypt": No such file or directory at pcf2vpnc line 30.
cisco-decrypt not in search path
 adding passwords in obfuscated form
vpnc config written to filename.conf with permissions '100644'.
Please take care of permissions.

In most cases, you can ignore the lines referencing cisco-decrypt.  cisco-decrypt is a program that can deobfuscate the passwords in a PCF file for use in other VPN software that does its own conversion.  In most cases, you shouldn’t have to do that.

Part 3: Connect to VPN

Still have that command line open?  Good.  Use it again to run this command:

vpnc filename.conf

Once that’s started, you should see something like this:

Enter password for username@

Go ahead and enter the password for the account “username” (if that isn’t your account, you need to modify the filename.conf file above, which is easy enough but out of scope for this post).  In my case, I have to use an RSA token to get in.  I enter the PIN, get the current code, type the code into the password above, and voila!  I get this (and you should see something like it for your connection):

Connect Banner:

You should see one more line after that if it works properly:

VPNC started in background (pid: 3199)

Now, it’s possible that you will run into another problem, as I did, where after a minute or so, you don’t see the line above but you get the following line:

vpnc: no response from target

This can appear for myriad reasons, but for me, the most common is that the VPN has become the default route for all traffic–even the traffic that carries the VPN itself.  Basically, the VPN is forcing itself over itself.  This doesn’t work because the carrier traffic can’t reach the VPN device.  How to solve it?  Well, the fastest way I’ve found (and which I admit is not the most elegant way) is to add a route for the VPN gateway to point to your default gateway.  Determine your default gateway (if you’re at home, it’s probably something like, but again the details of finding it are out of scope for this post) and add a host route to the routing table:

route add -host gw

If you need to remove it for some reason (such as mistyping something), you can run this:

route del -host

Make any necessary adjustments and add in the proper route.  You should then see this, more or less:

Connect Banner:

VPNC started in background (pid: 3199)

The route will go away when you shut down or reboot.  You can also remove it manually, though in most cases there is no harm in leaving it there as the traffic would be going to the default gateway in any case.

Part 4: Do a victory dance

Always do a victory dance when you’re done.  It doesn’t matter what it is, how long you dance, or whether it’s actually to music.  Pick something, make it your own, and do it when you succeed.

How to set up the Cisco VPN client on a Linux computer
How to connect Linux to a Cisco VPN using a PCF file

Leave a Reply

Your email address will not be published. Required fields are marked *