Walls of Fire

scott sappenfieldThe title of this post sounds a bit more alarming than it is, but then again, upgrading the firmware on something called a firewall can be a bit scary.  At the very least, it’s not something you take that lightly.  If you mess with the gatekeeper and it goes south, you have the potential to block off everyone from the outside world and vice versa (see sophisticated, super complex diagram to the right) and you have to resort to other things like failover or “business continuity.”  Who wants to do that?  Not I.

Anyhow, I just did two SonicWALLs and it worked out just fine.

This was the topology.  Firewall A, the primary firewall was running the enhanced 5.6 SonicOS.  Firewall B, the backup, was running the same.  High availability was activated in this scenario.  That means, if A goes offline for any reason then B takes over.  Also, A was running with preempt mode enabled.  And that means, if B is currently active and A comes back online, then A will automatically take back ownership as the active firewall even if B was running just fine.

My mission was to take A and B from their current firmware version of 5.6 to 5.8, the latest generally available public release.  Here was the process.

Obtain the binary

Obtain the latest binary from the vendor.  That’s easy, SonicWALL customers can download it from a secure portal.  It’s available as a “.sig” file.  It’s normally in the 30+MB range, not big.

Validate the binary

Naturally, SonicWALL gives you the MD5 hash signature to compare your download against.  Here it was: 093f3dd2e248bb0e8a99441794902271.  If you need to calculate MD5, SHA1 or other hashes and you’re on Unix, no sweat, piece of cake.  If you’re on Windows, again, no sweat, piece of cake.  In fact, I went ahead and tested one straight from the big guy MicroSoft and it seemed to work just fine.  It would be a fun exercise to build one yourself in Ruby or something.  For you Windows users, here’s how you’d run it against the downloaded .sig file.

>fciv sw_nsa-3500__eng_xxxxxxx.sig

You could even throw the hash in a XML file and compare a bunch of files using this program…something like this with a -verify option (or something close):

<?xml version="1.0" encoding="utf-8"?>
    <FCIV>
	<FILE_ENTRY>
		<name>sw_nsa-3500__eng_5.8.1.8.sig</name>
		<MD5>093f3dd2e248bb0e8a99441794902271</MD5>
		<SHA1> </SHA1>
	</FILE_ENTRY>
    </FCIV>

Upgrade the appliance

Anyhow, here was the actual firewall part.  Login to the appliance, navigate to the Settings tab (SonicWALL has a pretty nice GUI).

1. Click Upload New Firmware, locate your .sig file, upload it and wait for it to finish.  You will get a message asking if it’s ok to upgrade both A and B since hardware availability is turned on.

2. Once that’s complete, click Boot next to your new firmware.  Of course, you want to boot with the new firmware you just uploaded with current settings, unless you want default factory settings in which case you can choose that option to boot.

B will update and reboot, followed by A.  During the time A updates and reboots, B will become primary and active.  Once A finishes, it will take over (remember preempt mode).  That’s it.  No interruption of business during the process.

Verify, verify, verify and also test, test, test

This is where you want to spend considerable time verifying all your security settings and other stuff are as they should be.

You’re done.  SonicWALL makes it pretty easy.

Reset the Switch

Disclosure:  I’m not a network engineer and I’m not Cisco certified.  In fact, I’m not a network certified anything and never will be.

Whew, glad that’s out of the way.  So, I found two old, old, old switches lying around.  They were both 100Mbs Cisco Catalyst 2900 Series XL to be exact.  The dates on the fans showed 1999 and I talked to a guy that said they “were here before he got here” which would confirm the date sticker and explain all the dust they had collected.  Why not just e-waste them?  Well, I’ll tell you why.

There happened to be an older 100Mbs switch in operation.  And it didn’t have any backup.  If it died you could just replace it with a new switch.  Easy enough.  But, it seemed like such a waste to have things just collecting dust.  Light bulb, I have a plan!  Keep reading and you’ll find out that after all this work they’ll just keep collecting dust anyhow.  Sweet!

Here’s an inventory of all the stuff

cisco2900seriesxlThis is the switch I was working on

powercableThis is the power cable I used to power up the switch

ciscobluecableThis is a RJ45 cable I found to connect to the switch

rj45todb9This is a RJ45 to DB9 pin connector I used to connect the blue cable above to a laptop (had to find a computer with an I/O port, that’s tough these days; I found an old Dell Win XP laptop that did the trick)

rubberfeetDidn’t have ’em, but these are nifty rubber feet pads I wish I had to avoid scratching up the table

First switch

First things first, I needed to find some kind of administrator’s manual or something.  So I started googling around using terms like “access old Cisco switch” and “connect to Cisco switch.”  Finally though, I got smart and found a link to an actual Cisco’s administrator’s guide to the exact model I was researching.  In the manual (it’s really old), it said you connect to the switch using its command line interface through terminal-emulation software.  Ok, great, that sounds antiquated.  It is, but it’s also trivial and relevant.

Here’s what was involved.

Step 1.  Hook the switch up to the wall for power

Step 2.  Hook the RJ45 cable to the Console port on the switch.  Hook the other end to the DB9 connector and hook that up to the I/O port on the back of the laptop

Step 3.  Power up everything

Step 4.  Launch Hyperterminal (that program buried down in Program Files -> Accessories or something like that)

Step 5.  Connect to it on COM1 using 9600 baud, no parity, 8 data bits, 1 stop bit

That’s it.  I’m in!  I see a command prompt and everything.  There was a moment when I tried to connect through Hyperterminal that I thought to myself there’s no way this will actually work.  But it did and I felt like MacGyver.  So to wipe the device, here’s the commands I ran.

switch>en
switch>write erase
switch>reload
switch>show vlan (you should now see that only default vlan settings are present indicating everything has been wiped)

Nice, I’m back to an original default settings 100Mbs switch.

Second switch

Now this one was a bit more interesting.  In the end, I did all the things I did on the first switch, but something snagged me at first.  If I recall correctly, it was after I typed “en” at the switch prompt.  It asked for a password and of course I had no idea what that might be.  So I tried “cheeseburger” and “ghost” and for some reason neither worked.  Hmmm…there has to be a way to reset a password.  You’ll destroy the settings, but that’s ok, I’m after that anyhow.

Here’s what was involved.

Step 1.  Unplug the switch (remember it turns on as soon as it is plugged in)

Step 2.  Step 2 above

Step 3.  Hold down the mode button located on the left side of the front panel and then power up the switch

Step 4.  Release the Mode button when the LED above Port1x goes out.

Step 5.  Once on the switch prompt, issue these commands

  • flash_init
  • load_helper
  • dir flash: (make sure you type the colon)
  • rename flash:config.text flash:config.old (password definitions)
  • boot
  • (abort the initial configuration dialog)
  • en
  • rename flash:config.old flash:config.text
  • copy flash:config.text system:running-config (copy the config into memory)

Step 6.  Now let’s work on the passwords

  • conf t
  • enable secret <new secret> (this is what I needed)
  • If you need to do the vty and console passwords, best of luck.  Ok, here’s how you do it
  • line vty 0 15
  • password <new password>
  • login
  • line con 0
  • password <new password>

Step 7.  Finally, write that to memory using write memory

Whala (how do you spell that) – that’s it, password reset to what I want it to be.

Saving the running configuration

Ah, I learned something else too.  I setup a separate VLAN on one of the switches only to find that after reboots, my settings were lost.  Argh!

Turns out, a Cisco IOS router stores configurations in two locations – RAM and NVRAM.  The running configuration is stored in RAM and is used by the router during operation.  Any configuration changes to the router are made to the running-configuration and take effect immediately after the command is entered.  The startup-configuration is saved in NVRAM and is loaded into the router’s running-configuration when the router boots up.  If a router loses power or is reloaded, changes to the running configuration will be lost unless they are saved to the startup-configuration.

To save the running-configuration to the startup configuration, type the following from privileged EXEC mode (i.e. at the “Router#” prompt.)

Router# copy running-config startup-config

Collecting dust

At the beginning of this post I mentioned that these units went back collecting dust.  That’s true.  Why?  There’s no use for them as the original switches are still operational.  Good stuff.