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

  • Did you setup the NAT rules to External WAN (Address)?

    Managing several Sophos firewalls both at work and at some home locations, dedicated to continuously improve IT-security and feeling well helping others with their IT-security challenges.

  • 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 apijnappels

    apijnappels said:

    Did you setup the NAT rules to External WAN (Address)?

    The original message clearly shows the DNAT rules. Port 85 forwarding works exactly as expected. Port 6036 forwarding does not.

  • 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.

  • in reply to Trane Francks

    Hi,

    I don't find the required screenshots of the configuration. I suggested an automatic firewall rule as the orignal post reads that a manual firewall rule was configured after several attempts.

    What does the pcap reflect? Did you verify the packet communication through tcpdump?

    Did you try to verify the steps suggested by BAlfson?

    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,

    I don't find the required screenshots of the configuration. I suggested an automatic firewall rule as the orignal post reads that a manual firewall rule was configured after several attempts.

    The original post states: "DNAT with auto-firewall rules". My apologies if that was confusing. The manual rule was only added later to test/ensure that the device in question was able to pass all services without restriction, with no change in behaviour.

    What does the pcap reflect? Did you verify the packet communication through tcpdump?

    Unfortunately, I'm working remotely, thousands of kilometres away from the client site and only have access to network peripherals, servers and domain controllers. I could install WinPcap on one of the DCs, but I am extremely reluctant to do so. I currently have no easy means of sniffing the network and there does not seem to be a tcpdump executable in the ssh/bash login in the UTM 9 device itself.

    Did you try to verify the steps suggested by BAlfson?

    Yes. Everything checks out just fine. It's probably worth noting that I am not a stranger to port forwarding in the Sophos devices and have compared working (different model/manufacturer) devices on other client networks with the configuration used here and it is identical with exception of the ports and IP addresses. It's unfortunate, but I don't think I'll be able to troubleshoot this any further and will force the client to access the device's LAN interface by way of VPN, which works without issue.

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

  • in reply to sachingurung

    sachingurung said:

    Did you verify the packet communication through tcpdump?

    tcpdump.txt

    Here is output of a failed login from my external location. Definitely some packets across port 6036. I looked at it, but as a jack of all trades, it doesn't really tell me anything.

    Cheers.

  • in reply to Trane Francks

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Unfiltered HTML