Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Michael_Horne
Collaborator

Outbound HTTPS - Server Certificate not passing firewall

Jump to solution

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

0 Kudos
Reply
1 Solution

Accepted Solutions
Michael_Horne
Collaborator

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.

View solution in original post

0 Kudos
Reply
9 Replies
ottawacanada150
Advisor

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

0 Kudos
Reply
Michael_Horne
Collaborator

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

0 Kudos
Reply
ottawacanada150
Advisor

Sure, let me know how it goes.

0 Kudos
Reply
ottawacanada150
Advisor

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

0 Kudos
Reply
Michael_Horne
Collaborator

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

0 Kudos
Reply
ottawacanada150
Advisor

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

0 Kudos
Reply
Michael_Horne
Collaborator

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

0 Kudos
Reply
ottawacanada150
Advisor

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

0 Kudos
Reply
Michael_Horne
Collaborator

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.

View solution in original post

0 Kudos
Reply