Forum Discussion

Devlin_T_149357's avatar
Devlin_T_149357
Aug 11, 2017

SSL Forward Proxy Question

Hello all

 

We have a requirement to allow some servers in a DMZ to talk to a service on the internet. I was looking into the SSL Forward Proxy feature on the LTMs as this appears to provide the service we need. F5s documentation on this is rather weak and rushed. I am following this guide:

 

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-ssl-administration-11-6-0/13.html

 

Some (basic) questions I had on this:

 

  1. When I create a pool, presumably the pool members are the server IPs on the internet?
  2. The certificate I use on the Client SSL Profile (Certificate B in the link above) - does this certificate need to be signed by our internal CA, and if so, do we need to use a particular certificate template, e.g. Subordinate Certification Authority?
  3. In the Client SSL Profile, do we only (at minimum) need to configure the SSL Forward Proxy section?
  4. In the Server SSL Profile which certificate and key do we use? We need the LTM to perform MA with the server. Will this be a certificate generated on the LTM itself or do we need to import the cert + keys of the back end server and use those here?

Thank you.

 

application delivery
LTM
ssl forward proxy

9 Replies

Sort By
  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Aug 12, 2017

    Hi,

     

    Do you require a ssl forward proxy or do you want LTM to act as a forward proxy for https requests?

     

    LTM can act as a forward https proxy without forward proxy feature (and without license).

     

    SSL forward proxy feature is useful when you want to enable http security like URL filtering.

     

  • Paul_Williams's avatar
    Paul_Williams
    Icon for Nimbostratus rankNimbostratus
    Feb 01, 2018

    So, my question is, the above seems to be designed to operate when the clients and the F5 are in the same subnet. How would we make this work if the servers were not in the same subnet.

     

    I ask as we have a similar situation, but our clients (or in this case, servers) are in a different subnet and separated from the F5 by a firewall. Getting the traffic through the firewall is not an issue, but how would be get the client traffic to the F5.

     

    If the VS has an address of 0.0.0.0 - how would we route traffic to it.

     

    • Devlin_T_149357's avatar
      Devlin_T_149357
      Feb 01, 2018

      Hi Paul

       

      Using a wildcard VS shouldn't present any issues as long as:

       

      1. You have a route (default or specific) with the next-hop of the F5's self IP adjacent at Layer 2 to the firewall.
      2. You configure the wildcard VS to be enabled on the same VLAN as the self IP in point 1. This perhaps isn't strictly necessary but feels like the right thing to do.
      3. Configure the wildcard VS to listen on a specific port. Again, not entirely necessary but if you know the servers will only ever talk out using HTTPS, then why not.
    • Paul_Williams's avatar
      Paul_Williams
      Icon for Nimbostratus rankNimbostratus
      Feb 01, 2018

      Our anticipation was that we could point any internal traffic requiring SSL/TLS uplift to a generic virtual server listener on the F5 (using internal DNS with the same name as the public FQDN for each external name, all pointing to the one generic listener) and that the F5 could proxy the traffic on to the public FQDN, achieving TLS uplift at the same time. In other words, without a listener per FQDN that we want to uplift the SSL/TCL for – all to the same listener, and then passed through to the public FQDN from the back-end of the F5 – and without the need to distribute internal certificates and load third party certificates.

       

      However, we are having difficulty seeing how we can achieve this other than putting the F5 in-line (not practical) or reverting to the approach of one virtual server per external FQDN – but then having to issue internal certificates and load the third party certificate into the F5, per FQDN. This is what we were wanting to avoid due to the overhead of maintaining it

       

  • Paul_Williams_3's avatar
    Paul_Williams_3
    Icon for Nimbostratus rankNimbostratus
    Feb 01, 2018

    So, my question is, the above seems to be designed to operate when the clients and the F5 are in the same subnet. How would we make this work if the servers were not in the same subnet.

     

    I ask as we have a similar situation, but our clients (or in this case, servers) are in a different subnet and separated from the F5 by a firewall. Getting the traffic through the firewall is not an issue, but how would be get the client traffic to the F5.

     

    If the VS has an address of 0.0.0.0 - how would we route traffic to it.

     

    • Devlin_T_149357's avatar
      Devlin_T_149357
      Feb 01, 2018

      Hi Paul

       

      Using a wildcard VS shouldn't present any issues as long as:

       

      1. You have a route (default or specific) with the next-hop of the F5's self IP adjacent at Layer 2 to the firewall.
      2. You configure the wildcard VS to be enabled on the same VLAN as the self IP in point 1. This perhaps isn't strictly necessary but feels like the right thing to do.
      3. Configure the wildcard VS to listen on a specific port. Again, not entirely necessary but if you know the servers will only ever talk out using HTTPS, then why not.
    • Paul_Williams_3's avatar
      Paul_Williams_3
      Icon for Nimbostratus rankNimbostratus
      Feb 01, 2018

      Our anticipation was that we could point any internal traffic requiring SSL/TLS uplift to a generic virtual server listener on the F5 (using internal DNS with the same name as the public FQDN for each external name, all pointing to the one generic listener) and that the F5 could proxy the traffic on to the public FQDN, achieving TLS uplift at the same time. In other words, without a listener per FQDN that we want to uplift the SSL/TCL for – all to the same listener, and then passed through to the public FQDN from the back-end of the F5 – and without the need to distribute internal certificates and load third party certificates.

       

      However, we are having difficulty seeing how we can achieve this other than putting the F5 in-line (not practical) or reverting to the approach of one virtual server per external FQDN – but then having to issue internal certificates and load the third party certificate into the F5, per FQDN. This is what we were wanting to avoid due to the overhead of maintaining it

       

  • Joad's avatar
    Joad
    Icon for Nimbostratus rankNimbostratus
    May 21, 2018

    Hi all,

     

    is it possible to use a specific IP address for VS (/32) or wildcard VS is mandatory?