Thread Info
  • Locked Locked
  • Replies 13 replies
  • Subscribers 4 subscribers
  • Views 18604 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.
Parents

  • Hi,

    Select Automatic firewall rules and please post the screenshot of the associated configuration. 

    Thanks

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • in reply to sachingurung

    sachingurung said:

    Hi,

    Select Automatic firewall rules and please post the screenshot of the associated configuration. 

    The original message clearly shows that automatic firewall rules are enabled. Forwarding to port 85 works as expected; forwarding to port 6036 does not.

  • in reply to Trane Francks

    The symptoms are that I can reach the Q-See device login page externally, but attempting to login immediately returns "Connection failed!"

    Maybe you could show us a screencap of what you're describing.  To start trying to figure out what's going on, first try #1 in Rulz. If you get no hint from those logs, check that #3 through #5 are not the issue.

    Cheers - Bob

     
    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:

    The symptoms are that I can reach the Q-See device login page externally, but attempting to login immediately returns "Connection failed!"

    Maybe you could show us a screencap of what you're describing.

    I don't see how that would really help. It's just the Q-See's own admin-page popup describing "Connect Failed!" along with the URL of the destination. Anyway, as you wish:

    To start trying to figure out what's going on, first try #1 in Rulz. If you get no hint from those logs, check that #3 through #5 are not the issue.

    As for the rest of it, it's a bit mystifying. I turned on 'log initial packets' and see that both ports are being passed through. The issue seems to be that traffic on 6036 is not 'unmolested'. It is somehow not getting back and forth as it should. None of the relevant logs indicated anything is amiss whatsoever.

    Very odd, I must say. Thankfully, the client is being very chill about the whole thing.

Reply
  • in reply to BAlfson

    BAlfson said:

    The symptoms are that I can reach the Q-See device login page externally, but attempting to login immediately returns "Connection failed!"

    Maybe you could show us a screencap of what you're describing.

    I don't see how that would really help. It's just the Q-See's own admin-page popup describing "Connect Failed!" along with the URL of the destination. Anyway, as you wish:

    To start trying to figure out what's going on, first try #1 in Rulz. If you get no hint from those logs, check that #3 through #5 are not the issue.

    As for the rest of it, it's a bit mystifying. I turned on 'log initial packets' and see that both ports are being passed through. The issue seems to be that traffic on 6036 is not 'unmolested'. It is somehow not getting back and forth as it should. None of the relevant logs indicated anything is amiss whatsoever.

    Very odd, I must say. Thankfully, the client is being very chill about the whole thing.

Children
No Data
Unfiltered HTML