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 s...
Paul_Williams_3
Nimbostratus
NimbostratusSo, 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
