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)
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 wget http://svn.unix-ag.uni-kl.de/vpnc/trunk/pcf2vpnc
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:
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:
Once that’s started, you should see something like this:
Enter password for firstname.lastname@example.org:
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: CONNECTION ESTABLISHED. UNAUTHORIZED ACCESS TO THIS NETWORK DEVICE IS PROHIBITED.
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 192.168.1.1, 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 203.0.113.1 gw 192.168.1.1
If you need to remove it for some reason (such as mistyping something), you can run this:
route del -host 203.0.113.1
Make any necessary adjustments and add in the proper route. You should then see this, more or less:
Connect Banner: CONNECTION ESTABLISHED. UNAUTHORIZED ACCESS TO THIS NETWORK DEVICE IS PROHIBITED. 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.