Pfsense blocking Drucva InSync
-
Well that is FAIL to start with!! Especially with a proxy - if they are doing that no wonder they have problems with proxies ;)
Quite often proxy will not touch ssl traffic.. Unless specifically setup to do MITM, SSL interceptioni, SSL Bump and Splice, etc. etc.. So if they were doing it over the normal 443 port of ssl the proxies wouldn't mess with the traffic.
-
@stephenw10 Kindly guide me how to exclude that traffic from the port forward squid uses in transparent mode
-
Ok you need to bypass the proxy either by source or destination IP in the Squid Proxy > General tab > Transparent Proxy Settings section.
So if you just have one device accessing this service you can add it's internal IP in the source section there.
If you have numerous clients using this and they also need to use the proxy then you will need to bypass by destination IP so you will need a list of the server IPs being used which may be difficult. Create an alias and add them to that then add that alias to the bypass destination IPs field.
Alternatively you may be able to match and not NAT that traffic some other way. Perhaps they use a fixed source port given they're using SSL on port 80. Or maybe you can change that port and avoid it entirely.
Steve
-
Their docs say they don't use port 80 though....
https://docs.druva.com/001_inSync_Cloud/Cloud/020_Backup_and_Restore/010_Set_up_inSync/010_Configuration/Network_ports
Are you using SSL filtering in Squid?
A list of server IPs is going to be impractical here.
Steve
-
Am not using SSL filtering its unchecked/ disabled.
-
So back to the beginning - LETS SEE A SNIFF on your WAN!! Vs just your log... Then we will KNOW what is going on.. Vs just guessing..
You have destination IP? Then sniff on your want with that when you try and connect for backup.. Well will see the exchange for the ssl connection.
-
here is the Link for the capture behind firewall and on WAN .Check it out
-
Where were those pcaps taken? What were they filtered by? What was happening at the time?
-
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
