Network Blunders: ACL flub

Alright, this was the plan:

1. Translate connections outside on TCP port 3392 to port 3389 (RDP) on one of the inside hosts
2. Configure Access List on the WAN interface to only allow this connection from our office

Seemed simple enough, I did something similar a week back for a different client and had no issues; but this time..I broke something..

I went to paste the Access List Entries (ACE) I had prepared into Notepad, each entry contained "line" then a number, but I realized the "line" command was unrecognized on this device. So I figured since I'm not able to use the line command, I'll have to modify the ACL the old fashion way, by removing the whole ACL with the "no access-list" command and pasting my new ACL without the 'line' command. This did not go as planned at all. When I pasted the ACL into the config terminal, it stopped right at the beginning. I thought "ooh...fudge.", my PuTTY session just hung there and I could no longer PING or access the router.

I knew exactly what had happened, the ACL was still applied to the WAN interface, the router immediately started denying any traffic that did not match the few lines which I pasted. I tried not to look panicked but I was freaking out inside. I told my manager that I lost connection with the site, and he gave me the O.K to run like the wind and go onsite to fix the mess I caused. I arrived to the site relieved to find that nobody noticed the impact, they could still access resources on the LAN and internet; however, anyone connected remotely by VPN or Terminal Services definitely noticed it. So even though the impact was minimal, we still had to restore the router to the original configuration before the changes, so that meant rebooting it and causing a temporary outage.

We were provided an outage window in the afternoon to re-do the change onsite, while everybody was on lunch. Before then, I spoke to one of our senior consultants and he told me what I did wrong. Apparently the IOS does support the line numbering but not the same way as on the ASAs.

On the Cisco IOS software, the entries look like this

1 permit 192.168.1.0, wildcard bits 0.0.0.255

2 permit 192.168.2.0, wildcard bits 0.0.0.255

3 permit 192.168.3.0, wildcard bits 0.0.0.255

4 permit 192.168.4.0, wildcard bits 0.0.0.255

On the Cisco ASA software it looks like this:

access-list mylist line 1 extended permit tcp any any eq http

access-list mylist line 2 extended permit tcp any any eq ftp

access-list mylist line 3 extended permit tcp any any eq telnet

Using this newly acquired knowledge, I performed another ACL change for a client and they remained up and running smoothly.

Graveyard shift

I thought I would never have to speak those words again, but it turns out I'm involved with a network change tonight @ 11PM. Our client has been having performance issues ever since they switched ISPs, so they want me on site to troubleshoot after hours. I don't really have much tools at my disposal, but I'm going to be thorough and hopefully spot the problem and fix it. That is if I can get inside the building tonight!

Getting a Cisco Adaptive Security Appliance!

My coworker and I have been bugging our manager about procuring a Cisco ASA to play and get familiar with, to support our clients that have them installed. A couple of days ago, he replied to us saying they ordered a Cisco ASA 5505, and we should see it in the next couple of days. I can't wait to console into it!

Also, I found some really helpful Quick Learning Modules for the ASA 5505 on Cisco.com if anyone else needs training on them.

First client Demo

A couple weeks back, I was part of a demo or sales pitch for a potential client who was considering installing a ShoreTel system. This client used to be a a very large Oil & Gas company but has since downsized to less than 50 people, one of which was the head IT guy, who we were presenting for. Not being knowledgeable enough with the ShoreTel system to run with the demo by myself, I mostly kept quiet and just listened to Ben (my Project Manager) pitch the product. When it was time for Q&A, the IT guy, also named Ben, had a lot of tough questions for us; one that had us stumped, was when he asked about support for Secure Socket Layer (SSL) when logging into the Administration interface. A very reasonable question, but with me being the only technical guy, and being without the knowledge, we had to do some research before we could give him an answer; and I was the one to find out.

After spending an afternoon on Google, I wasn't finding any clear answers, I was even starting to lose faith in the product and thinking maybe it did not have the support, but even Cisco's CUCM has https on by default! 

Eventually, I started seeing the bigger picture of it, unlike CUCM which is an all in one appliance, ShoreTel requires you install Microsoft IIS before installing the server. I did some more Googling and found a document on how to enable SSL on the IIS Server. After installing a Certificate Authority, certificates, reconfiguring the website in IIS to require SSL 128-bit encryption, I tested it out and could confidently reply with Yes, the ShoreTel will support encrypted SSL sessions.

What a week that was!

ShoreTel and XIRRUS

Well, the first week has gone by and I already feel exhausted, but I'm starting to get the hang of things at the new job. We had a speaker come in and demo this wireless product called XIRRUS for us, which looks rather interesting and is said to do WI-FI differently than anyone else in the industry. A unit costs about $5,000 USD, but hopefully we get to start playing with an AP soon. Anyways, the past few days I have been getting trained on the ShoreTel Phone System, as we do a lot of installations and projects around it and are a certified reseller for the company. Because I have experience with VoIP, primarily in the Cisco world, I'm able to grasp this other vendor's product with ease. ShoreTel's IP Telephony solution is very similar to Cisco's, but they do things a little different if not easier when it comes to the administration, I believe. My Project Manager helping train me says we have approximately 8 ShoreTel projects/installations coming down the pipe, and a large deployment just around the bend. I can't wait!

Mid-week, I was shown the ShoreTel server installation process, then finally got to configure the phones on my own and test them out. The image below shows a ShoreTel IP Phone (aka ShorePhone) 265 with a ShoreTel BB24 24-line button box, and the second one shows some other phones I also setup.

Day 1 - Orientation??

Today, after returning from a nice chilly week in Montreal, I finally started my new job as an IT Consultant.

We all know how the first day or two of orientation goes like; you meet the rest of your colleagues, get setup with the payroll, and of course, configure a Cisco Aironet 1141 Access Point from scratch for a client! This is my first time ever touching one of these devices I've read so much about in my previous job, but hey, it beats the hell out of doing password resets for end users, so I'm not complaining. Anyways, I plugged in the power, the console cable and brought up a terminal to configure it, I've got the enable prompt now, time to run a 'config t'. Expecting a config prompt, I instead receive % Invalid input detected at '^' marker. I checked and double checked that I typed the command correctly, but still no luck. Being the new guy, I figured I must be doing something wrong, so I resort to consulting with my boss and other members on the team; they appear to be just as stumped as I am. 

OKAY, time to hit up my good friend Google for some assistance, and we're in luck! The first result pointed out that the IOS image preloaded with my particular part # was a Controller-based and not Standalone AP, luckily I've read a little about these devices in my previous job to know the difference, basically with the Controller-based (aka Lightweight) Access Points, all the configuration and management is done on a Wireless LAN Controller and downloaded to the AP; you CANNOT issue configuration commands like you would on any other Cisco IOS device, directly. Alright, so the solution seems simple enough, procure a Standalone version of the AP, but wait, even better, apparently we can just download and load the AP we already have with a Standalone image! :)

While I discovered all this info by myself (with a little help from Google) one of our senior techs in another city just figured it out too. Once we got the right image loaded onto the device, we could then enter configuration mode and dump on the config. I knew victory was mine once I got one of our test laptops associated with the SSID, although the DHCP config was missing, mission accomplished. So this is my first entry into the journal I will be keeping on my adventures at this new position, I hope this has been both helpful and entertaining to my fellow Cisco guys out there.

If any of you run into this problem, this is a great resource to steer you in the right direction

https://learningnetwork.cisco.com/thread/9562