• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 986
  • Last Modified:

Cannot consistently view security cameras through software provided. Firewall seems to be the issue?

I have a client with a Dedicated Micros DS1 video camera unit. In conjunction with DM network viewer software (http://www.dedicatedmicros.com/australia/support_downloads_online.php) I am able to view the security camera's in some circumstances.

The camera unit has been setup behind two different firewall units. A sonicwall TZ190 running enhanced firmware. A linksys WAG54G v3 wireless access point. Both running the latest firmware.
The camera server uses tcp and udp ports 8234 and 8235.

The problem is on the return to the person using the viewer software. Depending on the connection type the camera's can be viewed.

If I use a dialup connection the video streams successfully.
If I attempt to view from behind our sonicwall TZ170 standard at work it fails. The logs reveal the packets are dropped due to a Probable TCP NULL scan.

Various other combinations work or not. A 3G internet connection via a PCMCIA card works. While a motorola cable modem will fail.

I have tried creating an ANY rule on the firewall between the 2 addresses to no avail. I have played around with MTU setting and allowing packet fragmentation. No result.

Any help would be appreciated.

0
silky38
Asked:
silky38
  • 2
1 Solution
 
jsthursdayCommented:
you might need to forward the ports so the router reads them. it sounds like the ports are being discarded to the router as soon as they are hitting it. check out this site, its one of the best tutorial sites--

http://portforward.com/routers.htm
0
 
silky38Author Commented:
Thanks JS but I am already forwarding ports 8234-8239 to the unit through the firewall. The problem is not that the packets don't get forwarded. The problem is that the packets are detected  as a TCP NULL SCAN on the return trip by our Sonicwall.
The problem doesn't occur if you use a dialup connection and some routers such as my netgear wireless router have no issues either.
0
 
Freya28Commented:
if we send a packet to a remote system in which all the flags are turned off (That is, set to NULL), then the remote system would actually not know what to do with the packet or in other words, it would not know what this packet was meant for.

You see, each flag is supposed to perform a particular function. According to the function that you wish to perform, the various TCP flags are turned on and turned off. Now, when the client sends a packet with all the flags turned off, then the server has absolutely no idea as to what it has to do with the packet or as to why the client sent the packet. If the NULL packet is directed to an open port, then the service running on that port replies with a error message. However, if the NULL packet is directed to a closed port, then the remote system replies with a RST or reset because the NULL packet it received did not contain enough information to establish a connection.

0
 
silky38Author Commented:
Doesn't really solve the problem, but chances are that no one will have an answer.
0

Featured Post

When ransomware hits your clients, what do you do?

MSPs: Endpoint security isn’t enough to prevent ransomware.
As the impact and severity of crypto ransomware attacks has grown, Webroot fought back, not just by building a next-gen endpoint solution capable of preventing ransomware attacks but also by being a thought leader.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now