Web filtering https option in UTM console possibly mislabeled.

Bob,

I appreciate that and I know what 60001 means.  With the box unchecked the 60001 does not occur.  With the box checked the 60001 does occur somewhere in the middle of the communication; I conjecture connection has broken down, i.e. the UTM sees it as unsolicited traffic.  It was just something I noticed when I was debugging this problem.

Back on topic, uncheck the box the application works, check the box, it does not.  Ideally, the application should work with or without proxy, unless of course it is purposely configured to be filtered by the proxy.  Since I am still convinced that the box labeled 'Do not proxy https in transparent mode' is labeled backwards.  Can you point me to an easy test/example to convince me otherwise?  I assume I should be able to see something from a 'tail -f http.log'.

thanks,

Richard

Yes, tail -f /var/log/http.log would indeed do the trick, Richard.

I still think there' something else going on.

Cheers - Bob

Like I said, Richard, I think there's something else going on with the camera.  You can see if a PC browser's HTTPS traffic is handled by the Proxy depending on whether you check that box.  Give WebAdmin and the configuration daemon a few minutes to complete rewriting the code that runs the UTM before you test a change - I would expect this particular change to take place quickly, but I haven't tested it.

Cheers - Bob

Bob, Karlos,

Thanks for your replies and patience.  After further research I have concluded that the box is indeed labeled the way it is currently working and it is the proxy that is now allowing blinkforhome to work for me.  I was misled by at least three items: 1. I determined that AWS is now only supporting TLS 1.2 so it was difficult for me to reconcile why/how a very old Engenius wireless router allowed the cameras to work again (I can only conjecture that Amazon still has a common cipher active with the old router, and oh BTW, with the older cipher settings on the UTM).  2.  I had accidentally typed the wrong subnet prefix for the camera, so the camera's IP was appearing in the http.log after all.  3. I was not able to speak with a support engineer at Blink until late in the game and I'm not sure he was confident one way or the other about TLS 1.2 support.

I apologize, you were correct all along.  When the box is NOT checked, then proxy gets involved in https.  I do stand by the box should be relabeled to "Proxy HTTPS in transparent mode" and the code should be changed to match, but that is an interface opinion and at least the setting currently operates according to the current wording.

One strange anomaly, I did see a stray 'url=https://.....' a couple of minutes or so after I had checked the box and hit apply.  But, maybe that was just during transition to the other mode.  What is weird about that is checking the box and hitting the apply pretty much instantaneously breaks the cameras.  So, the problem is still a mystery since I had this box checked for at least a couple of years.  I am open to any ideas and will continue to talk with blink; I would think with the size of their customer base there would be a lot of complaints, but I would say by far most of their customers are using OTS cheap routers.  What settings are in play when the box is checked, is that just straight NATing?

thanks,

Richard

When the box is checked, it's the firewall rules that determine if the traffic passes and then, yes, you do need a Masquerading rule for the traffic.

Cheers - Bob

Bob,

Masquerading for that VLAN (3) is and has been in place all along.  So, there is some other reason why with the box checked the camera can no longer upload to AWS.  Is there a log snippet I can get you that may help to debug?

thanks,

Richard

Hey Richard,

Thanks for the update. As Bob mentioned, checking that box then passes the responsibility over to the Firewall to either allow or block the traffic. Have you filtered your firewall logs by the Camera IP/subnet to see whether packets are being dropped? You could also look into your IPS logs, if it's enabled. 

Cheers,
Karlos

Hi Karlos,

When the box is checked, the only logs where the camera's IP address appears are as follows:

1. confd-debug.log

2. confd.log

3. dhcpd.log

4. http.log

5. system.log

I don't think any of the logs will help us; number 1, 2, and 5 mention the IP only for license tracking; 3 has to do with the dhcp lease of the camera's IP; 4 has no log lines after I checked the box for this test.  I can use tcpdump to capture a trace from the camera, but I cannot determine why the connection terminates prematurely.  All of this worked prior to 1/18/2018.

From the Linux command line or the Web interface is there a way I can tell if any threat patterns were updated around that date?  I do not have automatic firmware update enabled and I don't recall updating the firmware around 1/18.

thanks,

Richard

As root:

 zgrep '"Successfully installed' /var/log/up2date/2018/01/up2date-2018-01-17.log.gz
 zgrep '"Successfully installed' /var/log/up2date/2018/01/up2date-2018-01-18.log.gz

Cheers - Bob