While troubleshooting a VPN connection I wanted to confirm that the pre-shared key is identical on both ends. In order to do so I used a cool, relatively unknown command that allow you to recover the pre-shared key:
Using the more system:running-config command result in clear text pre-shared key:
tunnel-group tunnel_name ipsec-attributes
While this is the easiest way, you might encounter a device with an old version (pre 7.x) that does not support this command. Don’t worry, there are more opitons. using TFTP you can copy the config to your TFTP server which saves the password in clear text. This is the required command:
copy running-config tftp:
You can also use the less known write net command for the same task. In both cases, the text file containing the configuration on the TFTP server will show the pre-shared key in clear text.
By the way, older ASDM versions will show the passwords in clear text but I hope you’re not using those old versions
After a long while I had a chance to work with our firewall. Part of the task was setting up our old PIX as DHCP server.
The configuration is simple:
dhcpd address 172.16.1.100-172.16.1.200 inside dhcpd dns 172.16.1.1 dhcpd wins 172.16.1.2
You can see that the configuration is really simple but I found on interesting detail I wasn’t aware of: You can only use 256 addresses
Well, to be exact it is 253 addresses and it is a software limitation:
The size of the address pool is limited to 256 addresses per pool on the security appliance. This cannot be changed and is a software limitation. The total can only be 256.
One note – this limitation is per interface so if you have more than one inside interface you can use 253 addresses per interface.
As I wrote in my last post, I’m working on a PIX to ASA migration.
One of the things that came up when I checked the PIX config is nat-control. What is it doing and should I use it in my ASA? Reading this post will answer some of the questions.
Historically, PIX required NAT translation for traffic flowing from one interface to another. It all changed in PIX 7.0 when Cisco added the nat-control command which let you configure your PIX\ASA to allow traffic to flow across without the usage of NAT.
How does it work?
You should decide using the nat-control command in configuration mode to specify if NAT is required for outside communications. When NAT control is enabled, configuration of NAT rules is required in order to allow outbound traffic, as is the case with earlier versions of PIX software (older than 7.0).
If NAT control is disabled (using no nat-control), inside hosts can communicate with outside networks without the configuration of a NAT rule as long as they have valid public addresses.
This is how it looks in ASDM:
- Translation method – this can be a static translation with the static command, or a dynamic translation with a nat or global rule.
- Access control list (ACL) – If an ACL is present, then it must allow the source host access to the destination host with the use of the specific protocol and port.
To figure out if nat-control is enabled or disabled, use this simple show command:
show run nat-control
When enabled, the output would be
When disabled it will show
To sum, newer PIX\ASA do not need require NAT configuration and you have the option to disable nat-control. You should figure out the types of connections you pass through your firewall and make a decision if you want to enable or disable nat-control. At least you have the option
Yes, I’ve been gone for a while. I’m busy with my Exchange work and studies and with everything else around me I hardly get to even look at my home lab. But as they say, good things happen to those who wait and we’re upgrading our company PIX to ASA so I have some real use for my Cisco knowledge.
When coming to perform this task there are few things to remember, I’ll review the most important points (at least as I see it).
First there is the technical detail – End-of Sale and End-of-Life for PIX is past due. The important meaning is that Cisco will not support PIX (so go ahead and either upgrade to ASA or find another solution), if you have issues with existing PIX you’re not going to get Cisco’s help and if (god help you) your hardware will die, you’re doomed…
You can always migrate manually (and there are some benefits here, I’ll get to it in a sec) or take the shortcut and use the configuration migration tool. If you’re not sure which option fits your knowledge and experience I bet the migration tool is your option, for the rest of you – read further to get the main points of each option.
So now that you’ve decided on performing the upgrade using the migration tool, check your PIX software version. If your PIX is running 7.X or higher you are in a good place as the configuration migration tool mostly match up your old PIX interfaces with the new interfaces of the ASA. If the number of interfaces on ASA is lower than the number of existing PIX interfaces you’ll have to use dot1q (if you want to use the migration tool).
The other less pretty case is when your PIX is running an older than 7.X version as you have to convert the PIX conduit and outbound commands. The rest of the process is similar, use the migration tool and you should be okay.
You might ask yourself why would you go the hard way and build your configuration manually? Like many times in life, sometimes it’s just better starting from scratch. When you build the configuration you have in mind the existing network environment with current and future needs. When migrating from existing configuration you tend to live the past, keeping old configurations (mostly access rules and objects) because they exist – not always because they are being used.
If you have the knowledge and time building new configuration is, in my opinion, the better option. You get a more accurate configuration that suit your needs and clean old unused objects. And there is one more pro, whether you’re the new guy in the company (as in my case) or a few year veteran that knows the network inside out – planning and building the new configuration let you get familiar with all the needs and review the method you’re using. Veteran’s tend to get stuck with their old doctrines and rebuilding can prevent it, make them rethink their work.
As I mentioned, I was checking for USB eToken implementation details as I was helping a friend to think through his token testing process. My friend was looking to utilize his existing eTokens and I was happy to play with this cool technology with him.
This feature provides primary secure means to store and deploy information separate from the router chassis, usually a bootstrap configuration or VPN credentials. This feature enables secure and portable loading of router credentials and configuration data supported by low-touch and enterprise level provisioning systems.
Using USB eToken you can also store passwords, IOS images and IPSec VPN credentials. This is called ‘Removable Credentials’ in the Cisco language.
Starting IOS 12.3(14)T Cisco support a USB Flash Module, hardware device sold by Cisco that expand the router capabilities on the 2800 series that I was looking at. The USB module come in 64, 128 or 256MB USB 2.0 versions, the eToken is also USB 2.0 device. USB Flash module can be used with any Cisco IOS feature set, IP Base and above.
I’ll show some basic commands, use this white paper for more details:
router(config)#crypto pki token default user-pin 0 1234567890
That would be an auto login command using the default PIN.
Another command change the user PIN from 1234 to 9753:
crypto pki token usbtoken0 admin login 1234
crypto pki token usbtoken0 change-pin 9753
Check this crypto pki command reference for much more.
The following is an output after the router recognize the eToken:
*Aug 22 10:34:44.060: %CRYPTO-6-TOKENLOGIN: Cryptographic Token eToken Login Successful*Aug 22 10:34:47.711: %USB_TOKEN_FILESYS-6-REGISTERED_WITH_IFS: USB Token File System usbtoken0 is registered…