SSLO HTTPS conversion to HTTP for NGFW inspection

Hi all,

I am new to the bigip SSLO and I was playing around it in order to see if I can enhance my NGFW visibility instead of moving to a bigger box.

The BIGIP has been moved as the default gateway for all users and acts as a transparent proxy. All users have been provisioned the CA certificate and exceptions for pinned and sensitive sites have been provisioned and working as intended.

The main idea is that I want to decrypt HTTPS traffic and send it over a Layer2/3 path via the NGFW in order to examine traffic and then re-encrypt it before been sent over to the internet.

I have everything working as intended except the HTTPS-to-HTTP-to-HTTPS.

Is this something which can be done by the SSLO?

Thank you

Konstantinos

Stephan_Schulz
Mar 29, 2023
Hi,

this is the use case for which the SSLO is build for, so yes it is (easy) possible to do this. In this case, the NGFW is just a service (inspection) device and SSLO will forward traffic based on your policy. There is one thing to consider in how to positioning the SSLO and NGFW. Is this NGFW the internet facing device with NAT, VPN, etc? If yes, it is a bit more complex as you can't move the device into the inspection zone completely.

From a SSLO perspective (best prectise) all inspection devices are hidden and isolated within a dedicated inspection zone and only the SSLO can forward traffic to them. It would be best to use a separate or a virtual instance of your NGFW as inspection device. Otherwise you can use PBR to steer the the traffic.

client --> (https) SSLO --> (http) NGFW --> (http) SSLO --> (https) NGFW --> (https) internet

The SSLO itself can be integrated as a L2 or a L3 device and it can work as a transparent or an explicit proxy. This really depends on your architecture or use case. You can find more details here: https://clouddocs.f5.com/sslo-deployment-guide/

Cheers
Stephan

Stephan_Schulz
Employee
Mar 29, 2023
Hi,

this is the use case for which the SSLO is build for, so yes it is (easy) possible to do this. In this case, the NGFW is just a service (inspection) device and SSLO will forward traffic based on your policy. There is one thing to consider in how to positioning the SSLO and NGFW. Is this NGFW the internet facing device with NAT, VPN, etc? If yes, it is a bit more complex as you can't move the device into the inspection zone completely.

From a SSLO perspective (best prectise) all inspection devices are hidden and isolated within a dedicated inspection zone and only the SSLO can forward traffic to them. It would be best to use a separate or a virtual instance of your NGFW as inspection device. Otherwise you can use PBR to steer the the traffic.

client --> (https) SSLO --> (http) NGFW --> (http) SSLO --> (https) NGFW --> (https) internet

The SSLO itself can be integrated as a L2 or a L3 device and it can work as a transparent or an explicit proxy. This really depends on your architecture or use case. You can find more details here: https://clouddocs.f5.com/sslo-deployment-guide/

Cheers
Stephan
Leslie_Hubertus
Ret. Employee
Mar 29, 2023
Konstantinos_Be - I'm going to mark Stephan's answer as an Accepted Solution so other users can find it easily in the future. Please let us know if this didn't answer your question, OK? 🙂
Konstantinos_Be
Altostratus
Mar 29, 2023
Hi Leslie_Hubertus ,
I can understand the "accept" criteria, however, I am seeing traffic as encrypted passing through the NGFW.
Do I need an iRule in order to decrypt it before been sent?
Thank you
Best Regards
Konstantinos
- Stephan_Schulz
  Employee
  Mar 30, 2023
  Hi,
  
  no, there is no additional iRule needed to decrypt the traffic, but maybe we should go back one step and verify how you have integrated the solution. I understand that the SSLO is integrated in L3-mode and it is behaving as a transparent proxy. How is the service for NGFW configured? Is it a L2 or a L3 device?
  
  In general, the SSLO will decrypt and forward traffic based on your security policy in combination with any dynamic service chain (see pictures below).
  
  With the security policy you define your criterias for a specific traffic type (i.e. URLs) and the action (allow, drop etc.). You can also configure if this traffic type should be decrypted or not and to which service chain it should be forwarded.
  
  Bypass means no TLS/SSL decryption
  
  if a service chain is selected, SSLO will forward the traffic to all devices in this chain
  
  You can configure different chains to involve different inspection devices in different order etc.
  
  To understand, why you are seeing encrypted traffic on your NGFW it is important to understand at which stage it has seen the traffic. Remember my previous answer, I don't know yet, but I assume your NGFW will see the traffic twice.
  
  If you see the traffic outgoing from the SSLO to the NGFW (you can verify this with tcpdump on the SSLO) within the inspection zone, then you should verify your security policy and the matching criteria for the traffic. You can also see the classification result in /var/log/apm (you should enable debug-logging for trouble shooting).
  
  Cheers
  Stephan
  - Konstantinos_Be
    Altostratus
    Mar 30, 2023
    Hi Stephan,
    
    I fully understand what you just described and thanks for the nice illustrations.
    I have configured the NGFW as a L3 service using the provided IP addresses (even through I cannot understand why I cannot use other private IP addresses).
    The L3 service can be viewed below:
    The configured security policy is the below:
    The SSL configuration is the below:
    The NGFW is deployed in the LAB as a service only. Traffic after the service chain is forwarded from the BIGIP SSLO to the internet router and NATted for internet access.
    The NGFW configuration is pretty straighforward as it can be seen below:
    
    Am I missing something?
    
    Thank you
    Best Regards
    Konstantinos
- Leslie_Hubertus
  Ret. Employee
  Mar 29, 2023
  That's a follow up for Stephan_Schulz - who I think is already offline for the day, but will hopefully come back tomorrow to reply.