Thread Info
  • Locked Locked
  • Replies 13 replies
  • Subscribers 4 subscribers
  • Views 18424 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DNAT port forwarding with Q-See camera only half-working

Trane Francks

Greetings, gang.

I need to get a Q-See camera setup working on a client's network. It seems simple enough to me, but I just cannot figure out why it isn't working.

Internal network:    192.168.1.0 / 255.255.255.0

Q-See Server:    192.168.1.245

DNAT with auto-firewall rules:

Any -> Q-See HTTP (TCP 85) -> External WAN
Any -> Q-See Server (TCP 6036) -> External WAN
Destination for both rules is above-listed Q-See Server internal address.

Manual firewall 'desperation' rule after many hours of struggle:

Q-See Server -> Any -> Any

The symptoms are that I can reach the Q-See device login page externally, but attempting to login immediately returns "Connection failed!", telling me that there is an issue with TCP 6036 port forwarding. Testing telnet to that port on the device internally, I see immediate activity:

Gaia:~ trane$ telnet 192.168.1.245 6036
Trying 192.168.1.245...
Connected to 192.168.1.245.
Escape character is '^]'.
head'1111^]
telnet> quit
Connection closed.

Connecting to this port externally, however, nets an entirely different and unexpected result:


Gaia:~ trane$ telnet xx.xxxx.co.jp 6036
Trying xxx.xxx.xxx.xxx...
Connected to xx.xxxx.co.jp.
Escape character is '^]'.
Connection closed by foreign host.

It's obvious that traffic to the ports is being forwarded to at least some degree. I port scanned the external interface and only TCP 85 is communicating. I am at a loss as to why connections from the WAN interface are summarily dropped on 6036, as the TCP service definition for 6036 has been checked and rechecked, and the port appears to be open to the external interface. Not dropped by the firewall, just summarily closing requested connections. Port scan results are different for each port:

Open TCP Port:     85             mit-ml-dev
Open TCP Port:     6036

I'm attempting to convince the client to simply access the device by way of VPN, but I would dearly like to know why this isn't working when I'm pretty sure that it should be.

Cheers,

trane



This thread was automatically locked due to age.
  • in reply to BAlfson

    BAlfson said:

    I might take one final stab at full NAT, but with the current DNAT difficulties, I would expect full NAT to break access completely

    If Full NAT works, it's an indication that 3.1 in Rulz is your problem.

    Cheers - Bob

    If 3.1 were the problem, it would be indicative that we'd managed to surrepticiously switch a universe where the laws of physics as we know it (and, therefore, networking)  do not apply. [:)] [:^)] [;)]

    We're getting traffic to/from the device at the firewall, which is the router and default gateway on the network. This means that 3.1 most assuredly is NOT the problem. The default gateway on the device is the same default gateway that the rest of the network happily uses. Network settings across the board are correct. It's 'my' network and I have admin access to the device in question. I confirmed that the network settings in the Q-See server are correct. We can talk to the device externally, but it doesn't function as expected via the external interface.

    It seems that traffic on port 85 passes back and forth unmolested. Traffic on port 6036 passes back and forth, but appears to be altered AT THE FIREWALL for some unknown reason. That's why I'm here: To discover the mechanism of why forwarding appears to be setup correctly, but the packets being passed across the firewall are altered on one of the ports.

  • in reply to Trane Francks

     I realize that you're frustrated, Trane, but you're making it very difficult for anyone to help you.  Did you try the Full NAT?  You say the port is altered - please show us the evidence from one of the logs mentioned.  Original data is clearer than a complete description.

    Cheers - Bob

    PS Fellow member wingman has a link in his signature here that you might find useful: How To Ask Questions The Smart Way.

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • in reply to BAlfson

    BAlfson said:

     I realize that you're frustrated, Trane, but you're making it very difficult for anyone to help you.

    Yes, I apologize for that. I think we got off on the wrong foot when I spent several messages answering questions that were already in the OP.

      Did you try the Full NAT? 

    Yes. Internally, the FQDN access worked fine. Externally, the behaviour was still showing the problematic symptom ("Connect Failed!" popup during authentication).

    You say the port is altered - please show us the evidence from one of the logs mentioned.

    Aside from initial packets showing up in white (on both ports), all logs show nothing of interest. "Altered" may be a poor choice of words on my part. It would probably be better to say that traffic across port 6036 differs depending on how one accesses it (internal network vs external over port forwarding). My concern here is that the Q-See Server clearly supports external support; UPnP and forwarding are both detailed in the user documentation, and nothing beyond straight-forward TCP forwarding is apparently required over the two specified ports.

      Original data is clearer than a complete description.

    Understood. Unfortunately, this has already cost the client a lot of money to not get working as expected and they're not excited about spending more to fix what should be simple. Since VPN access to the network is available to the same people who want to monitor this camera system, I have convinced them to just connect with the VPN and reconfigure their Q-See iPad and iPhone apps to use the internal IP address for the device. While I'm generally not a fan of workarounds, this one will do.

    Cheers and have a great day.

Unfiltered HTML