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

Hi,

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

Thanks

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.

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

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.

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

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. :)

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.

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

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

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.

 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.

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.