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…
I started a new ‘study from scratch’ Exchange blog.
Read all about it here: http://itdualismex.wordpress.com and bring your friends 😉
I’m a spoiled network admin – throughout my career I used only Cisco equipment.
Using only one vendor has a huge advantage as you have to learn one system, one syntax (yes, I know different devices or even IOS versions use different syntax but the major part never change). Using Cisco as your only vendor is expensive but if you can afford it the benefits are obvious: you get high quality hardware, great support (TAC), online documentation that is both easy to find and accessible and Googling any problem is easy, you always find a dozen of answers and useful information.
Before I continue two quick notes:
- As it was one of my first assignments I was anxious to prove my skills which mean make it work and do it fast.
- I’ll be more than happy to find a comment that would say something like:
“dude, you’re wrong! this is how you can do it”
The first step was finding the IPs of the 2 switches. As we didn’t know it I had to use Nortel’s Business Element Manager – their switch management tool. Couple of minutes later I found one of the switches and had no problem changing the IP. This is a screen shot of BEM with the 3 switches we have:
If you wonder, BEM’s scanning found another switch in a different site – a switch I wasn’t aware of. The one big problem with this tool is that it finds the switches by IP and since both local switches used the factory default IP – 192.168.1.132, I could only find one of them, had to change the IP and remove all previous data from BEM before I could find the second switch.
Victory was never closer. I opened PuTTY and tried to telnet the IPs I just assigned but…
Yes, every good story has its but 🙂
Telnet failed to connect and googling a bit I found that people mention ‘enable telnet-access’ command, not for my switch but I assume that Nortel’s default configuration disable telnet. I had to connect using console to make those changes.
When we found the right DB9 connectors and finally got into console mode (using Hyper Terminal for Win7) I had another surprise. While I expected a command line to show up (like a good Cisco device), this is what I saw:
Very limited, very old school and most important – no word on telnet or port monitoring.
It was time to find the Business Ethernet Switch 1000 Series guide and figure out what’s going on here. Reading the BES quick install guide (check this doc for the default password – it is kind of funny) just to confirm my finding resulted in the amazing sad conclusion: BES 1020 does not support telnet or port monitoring 😦
Yes, I checked the documentation few times (conig by BEM and config by Web – these are the 2 options), looked at the web configuration which has the same options as BEM and telnet does not exist. Oh, I miss my Cisco…
If anyone can correct me here I’ll be the happiest guy in the blog-sphere. If anyone has another idea on How to port-monitor this switch – stand up and HELP ME!!!