Forum Discussion

socvirgin23's avatar
socvirgin23
Icon for Altostratus rankAltostratus
Sep 19, 2023
Solved

SSL Bridging verification

Is there an easy way to veriify that SSL Bridging is working on an F5 LTM? I need to determine that an SSL session between the client and the F5 has been made and subsequently an SSL session between the F5 and the destination server.

I've asked F5 support and they have advised me to take packet captures or use an iRule but this seems a bit extreme. I dont want to look inside the SSL Bridging sessions I just need to confirm that SSL Briding is working.

We have an RDP issue where sessions are not automatically failing over if an RDP Gateway goes down. We think SSL Bridging will fix this and it has been configured at a test site but I need to determine that SSL Bridging is working properly before I roll it out to the 'live' site.

Any help would be appreciated.......

  • socvirgin23 The best way to verify this is to perform a tcpdump for the virtual server in question. You can be 99% certain that if you have SSL termination on the F5 and then re-encrypting when you send it to the pool member then that is what the F5 is doing. You should be able to use the following tcpdump on the F5 to save the capture and then open it up in wireshark and verify that the traffic is indeed encrypted.

    tcpdump -nni 0.0:nnp <virtual_server_IP> -w /shared/tmp/mycap.pcap

    The capture above will save itself to /shared/tmp/ as filename mycap.pcap so once you end the tcpdump that file should have all the data that you're looking for, provided that you tested that specific virtual server when you had the capture running. You should see two connection one between the client and the F5 and then another between the F5 and the pool member. You can track the tcp connection by looking for the ephemeral port that the client used because the F5 does its best to reuse that ephemeral port between itself and the pool member when forming that side of the tcp connection.

7 Replies

  • Can you explain your setup here?
    Are you running APM so the f5 is your RDP Gateway or is this a different solution?
    If you are doing decryption and encryption on the f5 there will be logs for that.
    Also tls is part of the layers 4- and above, so you should be able to see that there is a certificate in the traffic flow but it depends on how you are setup.

    • socvirgin23's avatar
      socvirgin23
      Icon for Altostratus rankAltostratus

       

      Hi PSFletchTheTek,

      No APM on the F5 it is just LTM. I have 2 virtual servers one configured for SSL Passthrough and the new test virtual server configured for SSL Bridging. The RDP Gateways are pool members and sit behind the F5's.

      Inbound RDP traffic from the internet hits the external Palo Alto firewall public ip and then gets NAT'd to the internal ip address of the virtual server on the F5. The Palo NAT rule currently points to the new test Virtual Server. The F5 then load balances the RDP traffic to the RDP Gateways.

  • socvirgin23 The best way to verify this is to perform a tcpdump for the virtual server in question. You can be 99% certain that if you have SSL termination on the F5 and then re-encrypting when you send it to the pool member then that is what the F5 is doing. You should be able to use the following tcpdump on the F5 to save the capture and then open it up in wireshark and verify that the traffic is indeed encrypted.

    tcpdump -nni 0.0:nnp <virtual_server_IP> -w /shared/tmp/mycap.pcap

    The capture above will save itself to /shared/tmp/ as filename mycap.pcap so once you end the tcpdump that file should have all the data that you're looking for, provided that you tested that specific virtual server when you had the capture running. You should see two connection one between the client and the F5 and then another between the F5 and the pool member. You can track the tcp connection by looking for the ephemeral port that the client used because the F5 does its best to reuse that ephemeral port between itself and the pool member when forming that side of the tcp connection.

  • Hey socvirgin23 - if this did indeed work for you - I'd like to share this back to our Support team so they may be able to leverage the simpler command going forward.

    Let me know - and thanks for being part of our community.

    • socvirgin23's avatar
      socvirgin23
      Icon for Altostratus rankAltostratus

      Hi LlefZimmerman,

      The command below worked for me just fine. I was able to see the Client SSL session to the F5 and the new Server SSL session from the F5 to the backend server in the packet capture which verified that SSL bridging is working.

      (tmos) # tcpdump -nni  0.0:nnp  host  192.168.207.30  -w  /shared/tmp/mycap.pcap