Forum Discussion
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:
Some (basic) questions I had on this:
- When I create a pool, presumably the pool members are the server IPs on the internet?
- 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?
- In the Client SSL Profile, do we only (at minimum) need to configure the SSL Forward Proxy section?
- 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.
natheCirrocumulus
This post has a really good write up on how to configure SSL forward proxy. F5 luminary Kevin Stewart provides a step by step. See SSL forward proxy what cert to use
Hope this helps
N
Stanislas_Piro2Cumulonimbus
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_WilliamsNimbostratus
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.
Hi Paul
Using a wildcard VS shouldn't present any issues as long as:
- You have a route (default or specific) with the next-hop of the F5's self IP adjacent at Layer 2 to the firewall.
- 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.
- 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
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
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.
Hi Paul
Using a wildcard VS shouldn't present any issues as long as:
- You have a route (default or specific) with the next-hop of the F5's self IP adjacent at Layer 2 to the firewall.
- 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.
- 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
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
JoadHi all,
is it possible to use a specific IP address for VS (/32) or wildcard VS is mandatory?
