The behavior was the same as when UI3 detected bad or suspicious packets - I think (though I can’t be certain) that UI3 sees those packets with the rewritten source address as broken or malicious. I can’t see inside BI and why exactly it is discarding them, but I watched with Wireshark as the packets were passed to UI3, yet it did not reply. This is because BI does not support receiving those modified packets Stunnel is sending.
Long Answer - There is no combination of technologies which will accomplish a transparent proxy to BI via Stunnel. Short Answer - I will be going the nginx route. I have searched for hours and it appears I am the only person on the planet experiencing this issue with Stunnel or BI.Īm I screwed? Does using Stunnel permanently nuke any ability to manage (or even view!) connections in BI, thereby making literally all of BI's Advanced Web Server tools pretty much useless? See screenshot "bi_https.png" which shows the two logins appearing as the localhost IP. The biggest issue with that obviously is that I (and BI) cannot ban IPs, automatically or manually, because it would be banning its own localhost IP, causing all sorts of problems. This is equally useless for identifying intruder's IP. Unsurprisingly this did not solve the problem at all - The users still all show up under the same IP, but that IP is now the host IP I entered into the config file. So, based on the best advice offered on and roughly 3 hours scouring this very forum, I changed my stunnel config file to specify my host's actual IP. When I log into BI using the secured HTTPS address (translating thru Stunnel), I can see each user login, but their source IP address is the same as the server address!! At first this was 127.0.0.1 (localhost), the Stunnel default (and perfectly fine for my use). See screenshot "bi_http.png" which shows two logins and their respective IPs. If I see a suspect IP and block it using the "Limit Access by IP Address" function, it blocks it. When I log into BI directly to the unsecured HTTP address (bypassing Stunnel directly to BI), I can see each of the user logins and their respective source IP addresses. This is where stuff stops working as expected. Naturally, the next step when exposing a server to the world is to ensure that it is secure, and even more importantly, make sure we can detect if (when) something worms its way past the VPN and starts hammering away at my BI login. That is all working fine - I can VPN in from work, navigate to BI's address with HTTPS, see my cams - all good, working as expected.
I have now set up a VPN gateway on my network that can talk to my BI server's subnet.
I have Stunnel set up for HTTPS webUI access on my LAN. You can run the script stunnel.I have BI running on a Win10 box, and for the most part I've got everything humming along smoothly.
STUNNEL UBUNTU INSTALL
Install and configure stunnel on Linux server It is recommended to use port TCP 443 or TCP 587 to hide the traffic so far. In reality SSL/TLS traffic is short and intermittent so still it would be easy for a goverment/ISP to detect stunnel since lots of traffic will be passed as SSL/TLS.
Since we need SSL/TLS handshake, if openvpn in the underlying protocol we need to use TCP protocol for openvpn. ConceptĪs you see in the above diagram, trafic encapsulates as SSL/TLS by stunnel regradless of it's internal protocol. Hiding openvpn traffic with stunnel so DPI firewalls are less likely to block your traffic.
0 kommentar(er)
