Explanation: F5 LTM Full-Proxy Architecture && SSL Bridging

Posted on

The concept of a full-proxy architecture, along with SSL Bridging has seemed to confuse a good majority of people to whom I’ve attempted to explain. In that light, here we go. I could write a long drawn-out explanation of this process (and will, if requested) but most folks reading this want a quick answer. Let’s proceed.

A few things to note:

  • “Full Proxy Architecture”, this means that clients or servers on either side of the F5 never talk to each other. The client thinks the F5’s endpoint (iApp) is the server, and the server thinks the F5 is the client. They never talk to each other.
  • “SSL Bridging”, this means Client -> F5 is encrypted, then decrypted for processing, then re-encrypted, and F5 -> server is encrypted.
  • “F5” is actually a company name, this products have many other names, such as F5 BIG-IP LTM ADC.
  •  It is a networking device, not a server, you can’t RDP to it like some people have assumed (although you can SSH into the management system and the TMSH data plane).

There is typically some confusion around what certs are on what box and whether or not they match. If they use the F5, the answer is – it doesn’t matter. They ONLY need to care about, and trust the cert that’s applied by the SSL Bridging profile attached the iApp that corresponds with the endpoint for that app. In the example I’ve drawn below (thanks to a fancy bright-link board) I show that the source client (which can be a server if you want), the F5, and the destination server all have different certs. Though, again all that matters to the anyone besides the F5 is the cert that the F5 uses. Note that the steps are numbered in green.


I hope this makes your day at least a little bit easier.




Server 2012 R2 “does not have a network adapter available to create a virtual switch” when configuring VDI

Posted on

I recently ran into this issue when doing an all-in-one VDI install, on top of a server that had been used for other things in the past. The “quick start” VDI option is supposed to essentially do everything for you, but I ran into this issue.

“The Server does not have a network adapter available to create a virtual switch”



Taking a quick look here, I do have a vSwitch. Why is it complaining?




It turns out that the installer isn’t actually complaining about the fact that there is no vSwitch, it’s complaining that there IS a vSwitch. It needs it to be a “blank slate” so it can manage it and do it’s thing. I’m not a fan of this, because I intend to manage my VDI environment using SCVMM, and the VDI component itself won’t have a whole lot to say about it. Nevertheless, this is how you get past this. Delete any vSwitches.





All gone, now try the installer again.





There we go, now we’re off onto the next step without any errors. Have fun!


I hope I’ve made your day, at least a little bit easier.


Wireshark not equal to filter

Posted on

I came across this today and thought I’d share this helpful little wireshark capture filter. Based on wireshark’s documentation if you use

“ip.addr !=” that should show you everything except for packets with the IP addrress The problem is … it doesn’t work. It turns yellow like this, and doesn’t filter that IP.



The trick is to negate the whole statement, then it will work. Instead of doing “ip.addr!=” run “!ip.addr==”. Wireshark then is able to read it as NOT  ip equal to, instead of IP is not equal to. Once you do that, you’re golden (well, green).



Simple enough, and it works with any statement — IE if you RDP into a machine and run a capture you should probably include “!tcp==3389” somewhere in your filter statement.



I hope I’ve made your day, at least a little bit easier!

Decrypting HTTPS (SSL/TLS) Tunnels Using Fiddler

Posted on

A few days ago the phone rings, I get an ear-full about how some application isn’t working correctly and how it’s all the network’s fault and the repercussions of this outage will possibly cause so much damage that the world will start turning…the OTHER DIRECTION. Unfortunately for us IT Professionals, this is all too common of an occurrence. Nonetheless, I jumped in to see what I could do. I had never seen this application before so I had to start troubleshooting from the ground up. Very quickly I noticed it was running (or supposed to be running) over web protocols, so I whipped out the handy-dandy wireshark to get a look. Hm…it establishes a TLSv1 tunnel and shoots all the data at the server that way. Well, the Apps team was no where to be found so I had to find out what was moving across the wire here to figure out the issue. This is where fiddler comes in to play *Trumpets Fanfare*.

Fiddler is a fantastic little tool that does different things with packet captures and things of the sort. For this blog, I want to talk about its’ ability to man in the middle your own machine to provide visibility into an encrypted tunnel. Lets do a little demonstration here.

I’ve done a quick search in on bing, using HTTPS — thing fancy here at all.




I started fiddler prior to performing the search above, and this is what it shows up with, a whole bunch of nothing. Tunnel Tunnel Tunnel Tunnel…dang security.




Alas, fiddler has an option to man in the middle yourself and decrypt the tunnel! Just go to Tools > Fiddler Options > HTTPS > and check the box that says “Decrypt HTTPS traffic”. I chose browsers only for this demonstration, though you can do all traffic for other uses and applications.




It lets you know that you’re doing something that defies the laws of CAs.



Now here we go, re-launch the browser and go to, it throws a security error stating that the certificate is untrusted.



For this to work, you will need to add the exception, if you view the cert you can see that it was assigned to fiddler, when it’s clearly stating that it is for



Once that is all excepted, you can do the same search we did before — plain and simple.



Back to Fiddler, and ta-da! Congratulations, you’ve bypassed the security of your own data and now have visibility into the tunnel.




That’s it, very simple. You can view inside your SSL/TLS tunnel using fiddler in just a few simple steps. Side note, I was able to use that to determine what was happening on the wire for my application failure and was able to remedy the failure.


I hope I’ve made your day at least a little bit easier!



Quick n’ Dirty Network Graph in Powershell

Posted on

This will be very short, sweet and to the point.

I was on a project recently where I was unable to access (and therefore monitor) any of the networking equipment and the WAN links thereof. Noticing that the issues that were occurring were due to a network problem I spoke with the folks who ran that particular network — they were no help. They gave me as little information as possible and punted the issue back to me saying it was a server problem. So here I am, no access to the network equipment, can’t monitor or log the WAN links, workstation in branch office having intermittent issues reaching the server in the main office. Enter powershell.

do {

#Ping and select only the response time then output to file
test-connection | Select-Object -Property ResponseTime >> pingoutput.csv

#Sleep for 10 seconds
Start-Sleep -s 10

#Write the time to the file
get-date >> pingoutput.csv

#Set the Time variable for the end while condition
$Time = (Get-Date).Hour


#While loop end condition states continue only if time is less than 5pm (24 hour clock)
while ($Time -le 17)

The comments in the script state how it works and what each line does. After 5pm (the while loop end condition) you can grab that output .csv file and pull it in to excel. Once there you select your data real quick and you’ve got yourself a nice little graph of network latency in milliseconds over the period of the day.



As you can tell there were some problems with this particular link.



There ya go!