The Worst Day Since Yesterday – Continued

First thing Friday morning, I followed up with the CIO to see if here iPad worked.  It was fine at home and worked at the office again.  Weird.

I put that thought to the side as I went to tackle the printers again.  Getting with the tech at the location I found that the problem still existed after cleaning up all the spyware.  So I gave him a systematic bunch of tests to try to see if we could localize where the problem was.  He timed everything from different documents to different user profiles to different PCs and printers.  After a few hours of that I would have some data to evaluate.

In the meantime, the calls didn’t stop.  More vendor calls.  More user calls.  And the support folks for our Guest Access system responded with a potential idea as to why the user the day before wouldn’t get the Captive Portal page.  I delegated this to one of my staff and then figured I’d send off the info for my CIO’s issue, to see if the problem was related, so I downloaded another set of tech-support dumps and forwarded them to Nevis Networks (the Security company for what I’m calling our Guest Access system.  Really it’s NAC, but we’ve not deployed it past it’s Guest access capabilities yet).  I have to say that although I’ve had issues with the devices themselves at times, I’m pleased with the support I’m getting from Nevis.  Yes, it’s in India and yes I have to wait overnight to get an answer, but typically they come back with useful solutions or tests to determine or fix the issue the very next day.  I’ve also been online with them for hours EST to work on some issues that needed hands on attention, so they are certainly willing to support their customers effectively, IMO.

The Worst Day Since Yesterday

Thursday was a very long day at work.  It seemed that everything wanted to happen all at once.  You know how those days go, I’m sure.  So, to make me feel better, I’m naming this blog after one of my favorite songs that I first heard on one of my favorite shows.

The day started with a plan, actually.  I’d noticed that the NAT rules on our core router were not quite functioning properly several weeks ago.  I’ve got multiple pools configured for different groups of systems (mainly servers, virtual servers, and clients, but also for each of our remote sites).  Apparently when I put this all together I fudged the ACLs that assign the IPs to those pools somehow, because I’ve noticed that some clients will translate properly, but others will translate into the server pools instead of the client ones.  Not a huge deal as far as access goes, since a public IP is a public IP and the client will be able to get to the Internet.  But the server pool has more privileges on our DMZ than the clients, so it could be a small security risk, if an employee wanted to do something they shouldn’t.

When the issue arose, I recreated the config in our test lab, recreated and confirmed the issue, and fixed the config to prevent the issue.  Problem solved, right?