Pfsense blocking Drucva InSync
-
they were taken while trying to run backup. One was done behind the firewall and another was done on WAN without the firewall
-
Ok yes I see the backup and indeed it appears to be using port 80.
The default port for that application is 443 though. If it has been deliberately changed then simply changing it back to 443 would solve this.Otherwise you will need to disable the proxy or bypass it for all traffic trying to use this.
Or potentially upload the proxy setup to each client, there does appear to be settings for that in inSync.
Steve
-
@stephenw10 said in Pfsense blocking Drucva InSync:
Otherwise you will need to disable the proxy or bypass it for all traffic trying to use this.
whats the best method to bypass it and how ? Is it possible to be done while still behind pfsene firewall ?
-
What are you backing up? Do you need this to work for a lot of clients? Do they need to use the proxy also?
The easiest thing to do here is just disable Squid for clients that need to use inSync. Or just disable it completely.
A better thing to do would be find out why it's using port 80 and go back to using port 443 if that can be done. Or even a completely different port.
Steve
-
We back up client data and sone critical audit files for a number of clients.
Let me see possibility of asking the Druva support on working on port 443 instead of port 80.The users need the proxy too.
-
You might try configuring the client to use the proxy directly:
https://docs.druva.com/005_inSync_Client/inSync_Client_5.8/002Install_inSync_Client/003_Configure_inSync/050_Configure_proxy_settings_on_the_inSync_clientEven there though it shows port 443....
Steve
-
Is there a way we can make sure that there is no sniffing for SSL packets or cipher packets coming from inSync cloud?
and also whitelist entire druva domain on TCP Port 80
-
if your client was using the standard port for ssl (443) then out of the box your proxy would not touch that traffic... Why is your client to run ssl traffic over 80?? That is BORKED!! Get with their support on how to get your client to run ssl traffic over the standard 443 port and your proxy issue goes away.
I don't get these companies thought process of designing their software to run ssl over a port that is not meant for ssl vs the standard port?? All they are going to do with such configurations is dick with shit working through a proxy. If it was say a standard alternative port 8443 or something that could be understood... But trying to run it over what is the standard clear http port, and not think you would run into proxy issues? I just don't get it... Pretty much any enterprise is going to be running a proxy - so what could they be thinking? Or did you clicking on shit change the port to 80??
It is standard practice for proxies not to dick with ssl traffic when its on 443... If I and anyone else should take away from this thread is not to deal with this idiot company ;)
-
If you can get a list of IPs their server are using you can bypass those as destinations for the proxy. But since they have presence across AWS it will be a very large list or maybe not possible at all.
Steve
