SSL Orchestrator Use Case: Inbound SNI Switching
Introduction SSLO will generate a single set of SSL profiles for use in a topology. It may be useful, especially in an inbound gateway mode, to process traffic to multiple sites, requiring different server certificates. The use case is to employ native BIG-IP SNI switching in SSLO, such that an SSLO topology can select a correct client SSL profile and server certificate based on the incoming SNI. In this example we have a single web server with multiple IP addresses hosting different web site domains: en.appserverone.com resides on 10.1.10.90 en.appservertwo.com resides on 10.1.10.91 When an external client requests https://en.appserverone.com we want the SSL Orchestrator to use a specific keypair for the sessions and direct the traffic to 10.1.10.90.When an external client requests https://en.appservertwo.com we want the SSL Orchestrator to use a different keypair for the sessions and direct the traffic to 10.1.10.91. Configuration Steps Import Private Keys and Certificates Create Client SSL Profiles Create a String Data Group* Import iRules Attach iRule to existing Topology Attach iRule to Existing Application Topology Attach iRule to existing Topology Interception Rule (alternative) *Note: You can either use an iRule and Data Group to match SNI to a Profile, or a static SNI-to-profile mapping in an iRule.The advantage of using a Data Group is all management is done at the Data Group. Import the Private Key and Certificate for the different web site domains From the BIG-IP Configuration Utility go to SSL Orchestrator > Certificates Management > Certificates and Keys. Click Import on the right. For the Import Type select Key. Give it a name, en.appserverone.com in this example.For the Key Source you can upload a file or paste in the text.We’ll use the Paste option which you can see below.Click Import when done. Click on the Key Name created in the previous step. Click Import. For the Certificate Source you can upload a file or paste in the text.We’ll use the Paste option which you can see below.Click Import when done. Repeat these steps for other web site domains.In this example we will add one more, en.appservertwo.com as you can see below. Create a Client SSL Profile for each certificate/key pair From the BIG-IP Configuration Utility go to SSL Orchestrator > Components > Profiles > Client SSL. Click Create on the right. Give it a name, en.appserverone.com in this example.Select the Custom box on the far right then click Add for the Certificate Key Chain. Select the Certificate and Key created previously and click Add.A Passphrase and Chain can be specified if needed.Click Add when done. Select the Advanced option next to Configuration. Scroll down and find the Server Name field.Enter the FQDN that external clients will request, en.appserverone.com in this example. Note: when an external client requests https://en.appserverone.com their TLS Client Hello will contain an extension value for ‘server_name’ field with a value of ‘en.appserverone.com’.We’re instructing SSL Orchestrator to use this Client SSL Profile when it receives this type of request from a client. Scroll to the bottom and click Finished when done. Repeat these steps for other web site domains.In this example we will add one more, en.appservertwo.com as you can see below. Create a String Data Group that maps the SNI to the Client SSL Profile. This step is only required if using the ‘in-t-rule-datagroup’ iRule. From the BIG-IP Configuration Utility go to Local Traffic > iRules > Data Group List. Click Create over on the right. Give it a name, SNI_switcher in this example and select String next to Type. Create a String that maps the SNI to the Client SSL Profile name created previously.Click Add. Note: If creating these profiles in other partitions, or if the VIP runs in another partition, it’s useful to prepend the partition name to avoid confusion. So, in this case, the client SSL profile would be: /Common/en.appserverone.com Repeat this step for as many mappings as you require.We’re doing two in this example and it should look like the following.Click Finished when done. Import iRules We will create two iRules from the following 1.library-rule: This rule is required. The next two iRules will make calls to the Library iRule to check the TCP payload for the ‘server_name’ field in the TLS Client Hello. 2.in-t-rule-datagroup: This iRule depends upon a ‘Data Group’ to map the SNI to the Client SSL Profile 3.in-t-rule-static: This is a static iRule does not depend upon a ‘Data Group’.This iRule contains the mapping of theSNI(s) to the Client SSL Profile(s) Note: Rules 2 and 3 perform the same function in a slightly different manner.We will cover both options but you can pick whichever one you want to use. Note: Using a data group or static iRule to switch the client SSL profile, requires a binary-scanning TCP iRule that may have an impact on performance Click Create over on the Right. Give it the name library-rule . Copy and paste the following into the Definition field: proc getSNI { payload } { set detect_handshake 1 binary scan ${payload} H* orig if { [binary scan [TCP::payload] cSS tls_xacttype tls_version tls_recordlen] < 3 } { reject return } ## 768 SSLv3.0 ## 769 TLSv1.0 ## 770 TLSv1.1 ## 771 TLSv1.2 switch $tls_version { "769" - "770" - "771" { if { ($tls_xacttype == 22) } { binary scan ${payload} @5c tls_action if { not (($tls_action == 1) && ([string length ${payload}] > $tls_recordlen)) } { set detect_handshake 0 } } } "768" { set detect_handshake 0 } default { set detect_handshake 0 } } if { ($detect_handshake) } { ## skip past the session id set record_offset 43 binary scan ${payload} @${record_offset}c tls_sessidlen set record_offset [expr {$record_offset + 1 + $tls_sessidlen}] ## skip past the cipher list binary scan ${payload} @${record_offset}S tls_ciphlen set record_offset [expr {$record_offset + 2 + $tls_ciphlen}] ## skip past the compression list binary scan ${payload} @${record_offset}c tls_complen set record_offset [expr {$record_offset + 1 + $tls_complen}] ## check for the existence of ssl extensions if { ([string length ${payload}] > $record_offset) } { ## skip to the start of the first extension binary scan ${payload} @${record_offset}S tls_extenlen set record_offset [expr {$record_offset + 2}] ## read all the extensions into a variable binary scan ${payload} @${record_offset}a* tls_extensions ## for each extension for { set ext_offset 0 } { $ext_offset < $tls_extenlen } { incr ext_offset 4 } { binary scan $tls_extensions @${ext_offset}SS etype elen if { ($etype == 0) } { ## if it's a servername extension read the servername set grabstart [expr {$ext_offset + 9}] set grabend [expr {$elen - 5}] binary scan $tls_extensions @${grabstart}A${grabend} tls_servername_orig set tls_servername [string tolower ${tls_servername_orig}] set ext_offset [expr {$ext_offset + $elen}] break } else { ## skip over other extensions set ext_offset [expr {$ext_offset + $elen}] } } } } if { ![info exists tls_servername] } { ## This isn't TLS so we can't decrypt it anyway return "null" } else { return ${tls_servername} } TCP::release } Click Finished when Done From the BIG-IP Configuration Utility go to Local Traffic > iRules > iRule List. Click Create over on the Right. Give it a name, in-t-rule-datagroup in this example.Copy and paste the following into the Definition field: ## SSLO SNI Switching Rule ## Date: July 2020 ## Purpose: Useful in SSLO versions 8.x and below to switch the client SSL profile based on ClientHello SNI ## in inbound SSLO topologies. This would be practical for L3 inbound gateway mode or L2 inbound topologies. ## Instructions: ## - Import server certificates and private keys ## - Create a separate client SSL profile for each cert/key pair ## - Create a string data group that maps the SNI to the client SSL profile name (ex. test0.f5labs.com := test0-clientssl) ## - Add the library-rule iRule to LTM (name "library-rule") ## - Add the SNI-switching-rule to LTM (name is arbitrary) ## - Create an L3 inbound gateway mode SSLO topology. Define a server cert/key to be used as the "default" (when no SNI matches) ## - Edit the L3 inbound Interception Rule and add the SNI switching rule. Deploy and test. when CLIENT_ACCEPTED priority 250 { TCP::collect } when CLIENT_DATA priority 250 { ## call the external procedure set sni [call library-rule::getSNI [TCP::payload]] ## lookup SSL profile in data group set sslprofile [class lookup ${sni} sni-switching-dg] if { ${sslprofile} ne "" } { set cmd "SSL::profile /Common/${sslprofile}" ; eval $cmd } TCP::release } Click Finished when done. Click Create over on the Right. Give it a name, in-t-rule-static in this example.Copy and paste the following into the Definition field: when CLIENT_ACCEPTED priority 250 { TCP::collect } when CLIENT_DATA priority 250 { ## call the external procedure set sni [call library-rule::getSNI [TCP::payload]] switch [string tolower ${sni}] { "en.appserverone.com" { set cmd1 "SSL::profile /Common/en.appserverone.com" ; eval $cmd1 } "en.appservertwo.com" { set cmd2 "SSL::profile /Common/en.appservertwo.com" ; eval $cmd2 } } TCP::release } Note: this iRule requires customization.The items in Blue are the Server Names that external clients will request.The items above in Red are the names of the Client SSL Profiles created previously. Click Finished when done Attach iRule to existing Inbound Topology If you have an existing Topology you can attach the iRule to that Topology.To do this you will need to disable Strictness on the Topology.From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration.Click the padlock on the right to Unprotect the Configuration. Click OK when presented with the following message. Note: Disabling Strictness on the Topology is needed to modify it and add multiple client-ssl profiles. Select Local Traffic > Virtual Servers.Click the name of your Topology, sslo_Inbound_Topology in this example. Scroll down to the SSL Profile (Client).Add the SSL Profiles created previously, 10.1.10.90 and 10.1.10.91 in this example.You also need a default SNI SSL Profile in case no SNI matches.We’re using clientssl in this example.Your screen should look similar to the following. Click Update at the bottom when done. Select Resources so we can attach the iRule. In the iRule section select Manage. Locate the iRule in the Available field.Select the one you want to use, in-t-rule-static in this example, then click the << to move it to Enabled.Click Finished when done. The configuration is now complete.When external clients request en.appserverone.com or en.appservertwo.com the correct Client SSL profile will be used. Existing Application Topology SSL Orchestrator manages the services and service policies for existing applications while an existing ADC application manages its own SSL settings and application delivery, consuming the SSL Orchestrator service policy information. The Existing Application topology is available for SSL Orchestrator addon licensed devices. ·Traffic flows into the BIG-IP. (This is configured outside of this topology.) ·Traffic is decrypted and sent to security devices. ·Traffic is re-encrypted and sent out to the applications. (This is configured outside of this flow.) From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration. Scroll down and click Next. Give it a name, Inbound in this example.Choose the Existing Application option and click Save & Next. On the Services List screen you can Add Services now or do so later.In this example we’ll have a Generic L3 Inline Service.Click Save & Next. On the Services Chain List screen you can Add or Edit a Service Chain.In this example it’s named ServiceChain.Click Save & Next. On the Security Policy screen click the pencil icon on the right to edit the Rule. Select the Service Chain and click OK. Click Save & Next. Review the configuration summary and make any changes as needed.Otherwise click Deploy. Add iRule and SSL Profiles to the Virtual Server From the BIG-IP Configuration Utility select Local Traffic > Virtual Servers.Click the name of the Virtual Server you want to configure, SNI in this example. Scroll down to the SSL Profile (Client) section.Highlight the SSL Profiles created previously and click << to move them to Selected. Scroll to the bottom and click Update. Select Resources to attach the iRule. Click Manage to the right of iRules. Select the iRule you want to use, in-t-rule-static in this example.Click << to move it to Enabled.Click Finished. The configuration is now complete. Attach iRule to existing Topology Interception Rule (alternative) Assign an iRule to the Interception Rule ·This incurs a performance hit without the SSL profiles attached to a VIP, but doesn’t require default-for-sni to be configured and does not require Strictness to be disabled on the Topology. From the BIG-IP Configuration Utility select SSL Orchestrator > Configuration. Select Interception Rules then click on the name of your Interception Rule, sslo_Inbound_App in this example. Click the pencil icon to edit the rule. Scroll down until you get to the section on iRules.Select the iRule you want to use, in-t-rule-static in this example and click the arrow to move it to Selected. Click Save & Next at the bottom. Click Deploy to complete the configuration. The configuration is now complete.SSL Orchestrator Use Case: Inbound SNI Switching with version 9.1
Introduction SSLO will generate a single set of SSL profiles for use in a topology. It may be useful, especially in an inbound gateway mode, to process traffic to multiple sites, requiring different server certificates. The use case is to employ native BIG-IP SNI switching in SSLO, such that an SSLO topology can select a correct client SSL profile and server certificate based on the incoming SNI. In this example we have a single web server with multiple IP addresses hosting different web site domains: en.appserverone.com resides on 10.1.10.90 en.appservertwo.com resides on 10.1.10.91 When an external client requests https://en.appserverone.com we want the SSL Orchestrator to use a specific keypair for the sessions and direct the traffic to 10.1.10.90.When an external client requests https://en.appservertwo.com we want the SSL Orchestrator to use a different keypair for the sessions and direct the traffic to 10.1.10.91. Configuration Steps Import Private Keys and Certificates Create Client SSL Profiles Create New SSL Configurations Add the Client SSL Profiles to the Interception Rule Import the Private Key and Certificate for the different web site domains From the BIG-IP Configuration Utility go to SSL Orchestrator > Certificates Management > Certificates and Keys. Click Import on the right. For the Import Type select Key. Give it a name, en.appserverone.com in this example.For the Key Source you can upload a file or paste in the text.We’ll use the Paste option which you can see below.Click Import when done. Click on the Key Name created in the previous step. Click Import. For the Certificate Source you can upload a file or paste in the text.We’ll use the Paste option which you can see below.Click Import when done. Repeat these steps for other web site domains.In this example we will add one more, en.appservertwo.com as you can see below. Create a Client SSL Profile for each certificate/key pair From the BIG-IP Configuration Utility go to SSL Orchestrator > Components > Profiles > Client SSL. Click Create on the right. Give it a name, en.appserverone.com in this example.Select the Custom box on the far right then click Add for the Certificate Key Chain. Select the Certificate and Key created previously and click Add.A Passphrase and Chain can be specified if needed.Click Add when done. Select the Advanced option next to Configuration. Scroll down and find the Server Name field.Enter the FQDN that external clients will request, en.appserverone.com in this example. Note: when an external client requests https://en.appserverone.com their TLS Client Hello will contain an extension value for ‘server_name’ field with a value of ‘en.appserverone.com’.We’re instructing SSL Orchestrator to use this Client SSL Profile when it receives this type of request from a client. Scroll to the bottom and click Finished when done. Repeat these steps for other web site domains.In this example we will add one more, en.appservertwo.com as you can see below. Create New SSL Configurations In this example an Incoming L3 Topology already exists.From the Configuration Utility select SSL Orchestrator > Configuration > SSL Configurations. Click Add Give it a name, appserverone in this example.Deselect the check boxes for Forward Proxy and Default SNI. For the SNI Server Name enter the FQDN, en.appserverone.com in this example For Client-side SSL select the pencil icon to edit the Certificate Key Chains. Use the Drop Down menu to choose the correct Certificate and Key, en.appserverone.com in this example. Click Done Click Save & Next at the bottom. Click Deploy Click OK to the Success message Repeat this step as needed.In this example another SSL Configuration is added for en.appservertwo.com. Add the Client SSL Profiles to the Interception Rule From the Configuration Utility select SSL Orchestrator > Configuration > Interceptions Rules. sslo_L3_inbound. Select the correct rule, sslo_L3_inbound in this example. Click the pencil icon to edit the rule. Scroll down to the Server SSL Profiles.Select the Server SSL Profiles created previously and click the arrow to move them from Available to Selected. At the bottom click Save & Next. Click Deploy Click OK to the Success message Summary Congratulations! The configuration is now complete
20 Lines or Less #29
What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week for the devcentral community, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head. 29 editions later and still going strong. The 20LoL is a testament to just how many different things can be done with iRules in just a few lines of code. Just imagine the possibilities if this were the 30LoL. This week I’ve got three more examples, all from the forums. Today we’ll cover dealing with port numbers in HTTP requests, checking pool status from within an iRule, and more fun with nested switching. The community keeps putting out fantastic examples so I just keep on writing about them. Keep it up. Removing HTTP request port numbers http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&postid=62227&view=topic Hoolio came up with a trio if examples of how to deal with port numbers in your HTTP requests. All of them are good, depending on your situation, but I’m only going to highlight one here. Go check out the forum post above to see the other two and get the context of the thread. when HTTP_REQUEST { # Check if Host contains a colon if {[HTTP::host] contains ":"}{ # Redirect client to requested host minus the port and preserve the original URI HTTP::redirect "https://[getfield [HTTP::host] ":" 1][HTTP::uri]" } } Checking pool member status http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&postid=62093&view=topic User cmbhatt, another one of our power-users, came up with a very cool example of using the LB::select command and HTTP::respond to show the status of a selected pool member. It even has a built in meta-refresh so you can continually monitor the status. Pretty neat stuff. when HTTP_REQUEST { if {[HTTP::uri] eq "/status" } { scan [LB::select] %s%s%s%s%d command current_pool command2 current_member current_port eval [LB::select] set response " $current_pool Pool Status - [clock format [clock seconds]]http://[HTTP::host]/status'>" if { [active_members $current_pool] < 1 } { append response "POOL NAME:$current_pool CURRENT MEMBER:$current_member:$current_port STATUS: DOWN " } else { append response "POOL NAME:$current_pool CURRENT MEMBER:$current_member:$current_port STATUS: UP " } } HTTP::respond 200 content $response "Content-Type" "text/html" } More nested switching and pool selection vs. redirection http://devcentral.f5.com/s/Default.aspx?tabid=53&forumid=5&view=topic&postid=62162 This rule stemmed from cmbhatt, once again, then I went in and made some tweaks where I think it made sense, as you can see in the thread. The idea is that the user is looking to do some inspection of first the host, then in some cases, depending on what the host is, the URI as well. Based on what’s found either a load balancing decision is made or a redirect is issued. This is yet another awesome example of how iRules can turn something that would be ridiculously tricky or even impossible elsewhere into something pretty straight-forward. when HTTP_REQUEST { switch [HTTP::host] { "www.mydomain.eu" { switch [HTTP::uri] { "/" { HTTP::respond 301 Location "http://www.mydomain.eu/zz/index.html" } default { pool mydomain_eu_pool } } } "www.mydomain.be" { switch [HTTP::uri] { "/" { HTTP::respond 301 Location "http://www.mydomain.eu/be/zz/index.jsp" } default { pool mydomain_be_pool } } } "www.mydomain.nl" { HTTP::respond 301 Location "http://www.mydomain.eu/nl/zz/index.jsp" } "www.mydomain.fr" - "mydomain.fr" { HTTP::respond 301 Location "http://www.mydomain.eu/fr/zz/index.jsp } "www.mydomain.lu" { HTTP::respond 301 Location "http://www.mydomain.eu/lu/zz" } } } There you have it, three more iRules to get you on your way in less than 21 lines of code. Feel free to submit ideas, suggestions of feedback, as always. #Colin20 Lines or Less #43 – Nesting, Rewriting Redirects and Auth
What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week for the devcentral community, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head. In the first 20LoL of the new year I bring to you a diverse offering of iRule goodness ranging from HTTP Authentication via iRule, to nesting switch inside if and why it’s important not to use elseif when doing so, as well as re-writing partial URL strings for redirection. Nesting switch inside if http://devcentral.f5.com/s/Community/GroupDetails/tabid/1082223/asg/50/afv/topic/aft/1176698/aff/5/showtab/groupforums/Default.aspx It earns cool points, in my opinion, to use logic in cool ways like this. The big caveat to keep in mind though is something that user TMaCEvans ran into, elseif. If you’re adding a switch statement inside your if logic keep in mind that the switch statement itself isn’t a valid comparison for the elseif operator. This means you’ll need to use a simple else and put the switch inside there with whatever appropriate logic you need, as Chris Miller pointed out in his helpful response containing this example: when HTTP_REQUEST { if { [string tolower [HTTP::path]] starts_with "/xyz/" or [string tolower [HTTP::query]] contains "xy=9" } { if { [HTTP::method] eq "GET" and [HTTP::header "Upgrade"] contains "WebSocket" } { HTTP::disable pool pool3 } pool pool3 } else { switch -glob [string tolower [HTTP::uri]] { "/fr/app*" { pool pool2 } default { pool pool1 } } } } URI Re-writing for redirection http://devcentral.f5.com/s/Community/GroupDetails/tabid/1082223/asg/50/afv/topic/aft/1176697/aff/5/showtab/groupforums/Default.aspx#1201401 User ukitsysadmin has been asking about how to take a part (the end) of an existing URI and use that as the key for a class lookup to find the new URI he wants to redirect users to. This is very doable and Aaron knocked out the more complex string parsing logic. I came in to finish up with a little class search/findclass goodness. I’m listing the v10 version of the example, even though it turned out ukitsysadmin is on 9.4.7. I just think class match is sexier than findclass. when HTTP_REQUEST { set uri_token [string range [HTTP::path] [expr {[string last / [HTTP::path]] + 1}] end] } when HTTP_RESPONSE { if {[HTTP::status] == 404} { set red_uri [class match -value $uri_token equals class_name] HTTP::redirect $red_uri } } HTTP Basic Auth via iRules http://devcentral.f5.com/s/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/1086387/HTTP-Basic-Access-Authentication-iRule-Style.aspx While digging through the forums I came across this post which talks about HTTP auth via an iRule. As Jason was kind enough to point out, George wrote this up in a Tech Tip a while back that showed how to do this clearly and to great effect. I figured I’d link to the full article as well as the post for clarity. This is a very cool technique that I can’t remember if I’ve highlighted here or not (130+ 20LoL code examples later…things tend to blend together), so I’m adding it here because it’s slick and can potentially be very handy. when HTTP_REQUEST { binary scan [md5 [HTTP::password]] H* password if { [class lookup [HTTP::username] $::authorized_users] equals $password } { log local0. "User [HTTP::username] has been authorized to access virtual server [virtual name]" # Insert iRule-based application code here if necessary } else { if { [string length [HTTP::password]] != 0 } { log local0. "User [HTTP::username] has been denied access to virtual server [virtual name]" } HTTP::respond 401 WWW-Authenticate "Basic realm=\"Secured Area\"" } } There you have it, some more cool iRule examples to remind you just how powerful this stuff can be in less than 21 lines of code. Pass it one, send some feedback, make some requests to let me know what you’d like to see next time, and I’ll be back with more as always. #Colin
Virtualization: How to Isolate Application Traffic
Many people are concerned with virtualization security (already coined VirtSec), and they're applying that concern from the virtual images all the way down the stack, to the network infrastructure through which virtualized application traffic is delivered. The desire for network infrastructure to be itself virtualized is growing out of a perceived need to isolate application traffic at every point in the infrastructure. But the technology to isolate application traffic at layer 2 and 3 of the infrastructure already exists, and has been essentially virtualized for years. The sudden desire for everything in the infrastructure to be virtualized completely is borne primarily out of security concerns. When you're running two or three or more virtual images on the same server it's natural to want them to be isolated from one another, so that a potential problem with one does not affect another. Too, it's an issue with keeping application data segmented, separated in order to clearly delineate the delivery path and to keep each stream of traffic pure. Of course that's amusing as multiple applications deployed on the same application server container, such as IBM WebSphere or Oracle/BEA WebLogic, cross the streams necessarily, so the sudden "OMG we have to isolate traffic completely" is a bit incongruous with most architectures, but c'est la vie, right? This leads to the belief that routers, switches, and application delivery solutions must be virtualized and compartmentalized such that application data is isolated even as its traversing the network. But the actual mechanism for how this is accomplished does not need to mirror virtualization as it is understood at the operating system or application level because for many years we're have something called VLANs (Virtual LAN) that performs this task for us already. VLANs are a standard layer 2 mechanism for segmenting and effectively isolating application traffic. Data on one VLAN cannot be seen or accessed by data traversing another VLAN, they are effectively separate streams. It is interesting to note that VLANs are one of the core technologies used to implement solutions such as NAC (Network Access Control) because it does the job and isolates "good" traffic from "might be bad" traffic in order to preserve the cleanliness of the network and protect access to resources. How the VLANs are used is part of the secret sauce of NAC and related technologies, with user traffic being moved from one VLAN to another as it moves through the authentication and authorization process. There's more to NAC than this, of course, but VLANs are almost always part of the equation - because they do the network side job so well without incurring the additional overhead of new infrastructure solutions. That's because traffic assigned to different VLANs is isolated. Traffic on one VLAN cannot be seen or accessed by traffic on another VLAN. Servers on one VLAN cannot talk to servers on another VLAN unless a switch or router or other routing-capable device allows the traffic to pass across the VLANs. VLANs are supported by all layer 2/3 capable devices today, which means just about everything - from routers to switches to load balancers to servers. The problem is that we've grown to use VLANs as an architectural tool rather than a security tool, and often don't consider how valuable such a simple, existing technology can easily be applied to more emerging, cutting edge concepts. In fact, VMWare has an excellent white paper on how to configure ESX 3 with VLANs using vSwitches that not only explains how to configure ESX to take advantage of VLANs, but also discusses VLANs in general including various approaches and their relative merits. There's a lot of new technology you need to acquire and implement for a successful virtualization initiative, but products that specifically isolate application traffic using nifty new virtualized systems is not necessarily one of them. I'm sure there are architectures and business reasons why you might need more, but if you're just attempting to isolate application traffic as due diligence, you may be overanalyzing the situation. Your existing infrastructure is almost certainly VLAN capable right now, and can likely be used right now to accomplish your goals of isolating application traffic. Sometimes the answer to a problem really is an existing technology or solution, you've just got to cut through the hype out there to find it.
