Tuesday, August 21, 2012

Issues with camera system

At work we have a 12 camera Geovision surveillance system that runs a TCP/IP service allowing LAN users to access the system and a Web service allowing authorized WAN users/devices to access the system from outside our network. This has been in place for at least 2 years now. Well, the other day I decided to access the system from home to see if our PTZ camera was working (I had heard a complaint). I couldn't connect. More specifically, using the external IP and the port number only resulted with Google telling me it couldn't find anything related to such madness. Curious, I contacted my boss and asked him the last time he accessed the system from his iPad (geovision app). He told me it had been a long time and to not worry about fixing the problem until the next day at work. Cool.

When I arrived at work I checked the following, but I didn't follow my policy of starting with external then going internal; if I had, then I would have fixed the issue sooner. What I did was start the complete opposite. Doh!

What I did

Began with the camera server. I checked the local firewall settings. Windows Firewall was on and allowing exceptions. I had all of the correct exceptions checked too. I then moved to turning off the local firewall on the camera server and accessing externally, but that didn't work. The Web Cam service was running also on the camera server. So, no problem with that device.

I then move to what I should have checked to begin with: Sonicwall. I checked the access rules, but I didn't see anything out of the ordinary. Everything we use was right there in the list. I then go to the NAT policies. Ah-ha! I see an odd NAT service called "our server name"-services with http and https. What? My comment on the NAT rule sucked too: sick/vacation. That didn't make sense to me because I had the correct mail server stuff running and I couldn't imagine why this NAT rule could be used for mail server stuff. My geovision services use http (8080) for the web access and this random NAT service also using 8080 was conflicting with the geovision service, which is why we couldn't access the camera system externally. I turned off the random NAT rule, tried the web cam externally and like a charm I was able to access the camera system. It wasn't cheer time just yet though because I had to make sure our mail service with our employee self-service system was still running with that random NAT service turned off. I tried it out and yes, it still worked.

What did I learn from this experience? I learned a few things (things I already know, but haven't put into habitual practice yet - FAIL).

1. Work from external to internal. Working this way keeps things simple because it's easy to get the external stuff out of the way first since there aren't as many things external as there are internal.

2. Document clearly. Even non-firewall things need to be documented clearly. When you're doing something at your work leave notes on why you're doing this or doing that. I have no idea why I made that NAT rule and the comment didn't help me at all. I was testing something, but failed to turn it back off. If I had documented clearly then I would have known the purpose of that NAT rule.

3. When you turn a service off or on or replace/whatever make sure your production services are running just as they should be. You know you've done something right when the only thing the employees notice is the new thing they were expecting or nothing at all after your network project.

No comments:

Post a Comment

Life in IT appreciates and encourages your comments, but we do have guidelines for posting comments:

1. Avoid profanities or foul language unless it is contained in a necessary quote.

2. Stay on topic.

3. Disagree, but avoid ad hominem attacks.

4. Threats are treated seriously and reported to law enforcement.

5. Spam and advertising are not permitted in the comments area.