Outbound HTTPS - Server Certificate not passing firewall

[Michael_Horne]

Hello All,

We have a strange situation for an outbound HTTPS connection that is going to a over a VPN to an external partner. We have confirmed that the TCP connection is up. We see the TCP 3-way handshake is completed. The issue is that when the server sends its certificate to the client, this server certificate is not received on the client.

The HTTPS inspection policy is bypassing the traffic

This is HTTPS using TLSv1.2 over the standard port 443.

The firewall cluster is R80.30

In SmartDashboard we have disabled a lot of the HTTPS validation.

There are no log entries for HTTPS inspection, even though the bypass rule should be logging the connections.

To be on the safe side we have imported the CA certificate as a trusted CA on the firewalls.

Has anyone had a similar situation or can offer some suggestions?

Many thanks,

Miahael

[the_rock]

Michael,

Let me try and help you offline with this, just shoot me a message and we can connect. I had been working with couple customers myself for https inspection, so Im somewhat experienced in it (anyway, dont get too excited now, haha). I believe remote session would help, so just let me know where you are located and we can set something up. I am in Canada (est).

Cheers,

Andy

[Michael_Horne]

Hello Andy,

Thanks for the offer, I have session planned already for this week. If this does not resolve it then, I might need your help.

Many thanks,

Michael

[the_rock]

Sure, let me know how it goes.

[the_rock]

Also Michael, I think it might help in the meantime if you can attach maybe the error you get, it may give some clues.

Andy

[Michael_Horne]

It seems that our problem matches the following:sk166532 

We have put in the workaround mentioned until we can identify the problem exactly.

Regards,

Michael

[the_rock]

Interesting...but isnt that same as doing full bypass, which literally renders https inspection uiseless? : )

[Michael_Horne]

Hello,

At the moment it is just a workaround. I am still working with TAC to identify the issue here. When I know more then I will post it.

Regards,

Michael

[the_rock]

Fair enough...Im happy to do remote if you are willing to, BUT, it would only make sense when its in broken state. Let me know.

Cheers,

Andy

[Michael_Horne · Accepted solution]

Hello All,

The solution to this problem was to re-order the rules in the HTTPS inspection policy.

The basic cause was that the firewalls were doing SNI probing of the site and this was failing,  It was failing as the site is only reachable via a VPN and when the firewall was doing the SNI probing the probes did not match the VPN and went direct to the Internet and failed.  

Even though the HTTPS bypass rule was only using destination IP addresses to match, there were rules about it in the policy that were matching a URL / host.  So to see if the traffic for the remote server was possibly matching the URL rules above the bypass rule it had to do SNI probing.

The final solution was to move the HTTPS bypass rule for this server above all bypass rules that were using URL / hosts to match.  

This meant that the HTTPS bypass rule was matched based on IP address before it had to test a rule based on URL / hosts.

[bbdgr]

This has just helped me fix an issue.

A client making a call-home connection to an external public server which uses private certificates.

In SmartConsole logs the connection look fine and allowed with no inspection.

But we also saw logs of the firewall's public IP accessing the same server.

In a packet capture on client side, you could see the 'client hello' was being sent a RST back from the server IP.

But on a server side capture, you could see a full handshake.

In turns out this starting after we had enabled Microsoft Tenant Restriction, and places the inspect rule for the Microsoft login pages, above the bypass previously allowing this connection to work. Moved the bypass above and hey presto, thank you 🙂

[the_rock]

Good job!

Best,

Andy