Pfsense blocking Drucva InSync
-
What exactly is being blocked? Do you see anything in the firewall logs?
What errors are you seeing that make you think something is being blocked?
Steve
-
We checked that with the druva support team when behind the pfsense firewall We get the below logs in inSyncClient.log
0_1550471243518_Insync Logs.txtBelow is the reply from Druva Online support team
From the logs, it seems that inSync client is not able to validate the SSL certificate that inSync cloud sends.-We took network capture to check the network traffic and below was the response from the Druva support team.
We found that the inSync client is sending "Client Hello." packet but it is not receiving "Server Hello" packet. We suspect that the firewall is blocking the SSL/Cipher packets coming from inSync cloud. "Server Hello" packet is the one in which the inSync cloud sends the certificate and post then the inSync client will trust the same and then will proceed with the data transfer. -
Where did you run the packet capture.
If you run it on the WAN do you see the client 'Hello;' and the server 'Hello' response from the remote end?
Does that not get passed back to the client if you run a capture on the LAN side?
'SSL routines', 'SSL3_GET_RECORD', 'wrong version number'looks more like it's receiving a bad reply from the server end with the wrong encryption type. Or maybe it's not hitting the server at all. Are you running Squid?Steve
-
Yeah I would also check you do a sniff on the wan.. You will see the server hello or not.. And sniff on the lan side will show you if pfsense sends it on to the client.
Pfsense would not filter the server hello.. Just doesn't work that way.
Did you happen to update anything on your box.. Say openssl or something?
-
yeah am using squid proxy server in transparent mode.
When running without firewall it goes through and backup successful.we used network monitor tool on the client machine and they description of the problem was :Backups fail in the networks having proxy servers or firewalls.
Check the attachment for description of the problem.
Is there a way I can get the Druva support on board to describe explain it more ? He said, in case I need to bring him on board I can let him know to bring a clear understanding.0_1550496733640_druva support.txt
-
Test it with pfsense, but without the proxy!!! Is your proxy doing ssl? If so quite often THEY do not trust the cert, etc. Or if doing mitm the cert handed back is not trusted by the client.
Just BYPASS this dest from using the proxy..
There is a HUGE freaking difference between what firewall does with traffic (NOTHING!) Its either allowed or denied.. And what a proxy does with traffic..
-
@philipo said in Pfsense blocking Drucva InSync:
yeah am using squid proxy server in transparent mode.
When running without firewall it goes through and backup successful.Ah, well there you go! The application is probably seeing either an error page or a cert error.
That traffic will be sent to Squid because for some unknown reason:
'The backup runs on TCP SSL port 80 .'You need to exclude that traffic from the port forward Squid uses in transparent mode.
Steve
-
Where did you see was doing ssl over 80... Yeah that would break the shit out of ssl and a proxy normally ;)
-
On the dupe post
https://forum.netgate.com/topic/140489/backup-fails-with-ssl-or-certificate-error-during-certificate-validation-behind-pfsense-firewall
-
Yeah see it now - yup what is pretty much BORKED right out of the gate!!
-
@johnpoz they told me it uses port 80 over SSL.
-
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
