The Port Mapping dialog – one dialog that does it all

This post was written by Gennady Gorenshtein, from the LoadRunner R&D Team)



The Web (HTTP/HTML) protocol is the most commonly used of LoadRunner’s vast range of protocols.  This protocol adds a dialog to the Virtual User Generator (VuGen) called the Port Mapping dialog, which allows you to perform some very important configurations.


In this post, I’ll explain the importance of this dialog, and how you can use it to configure your VuGen scripts.


This dialog was initially designed with one purpose in mind: to allow special treatment of certain IP addresses and ports during the recording. Over time, we added more and more functionality to it.


I’ll describe the dialog’s capabilities by presenting some of the most common usage scenarios. 


Scenario 1: Recording all of an application’s HTTP activity

This is the simplest scenario, and just uses the default settings of the Port Mapping dialog. No changes to the dialog are necessary.



Make sure the default Capture level (‘Socket level data’) is selected.  This is actually the default capture level that we’ll use in all of the scenarios in this article.


Scenario 2: Capturing all HTTP activity except messages sent to server

This situation can arise when some network traffic is not part of the business process. For example, whenever Google’s Chrome browser is used, Google’s own servers are constantly updated about the user’s browsing patterns. To exclude this traffic, the Port Mapping dialog setting needs to include an entry for the appropriate server (in this case,, and this entry must be disabled.  Click on ‘New Entry’ in the dialog, and the following dialog will open:





Scenario 3: Capturing all HTTP activity except messages sent to a specific port on server

You want to exclude HTTP traffic sent to port 80, but include other types of traffic, e.g. SSL (which is routed through port 443).


Specify the port number to be excluded, in the ‘Port’ setting of the ‘Server Entry’ dialog.   The Port Mapping dialog should look like this:



Scenario 4: Capturing traffic to server on port 80 only, disregarding all other traffic

The dialog will include two entries:

  • A disabled entry for all servers
  • An enabled entry for

It should look like this:



Scenario 5: In addition to the previous scenario, capturing SSL traffic to, on port 443

Let’s say that the SSL version used there is SSL 3, and the SSL cipher is RC4-SHA.  Create a new server entry which specifies the SSL version and ciphers:



The new entry is enabled in the Port Mappings dialog as follows:



Scenario 6: Recording an application that uses TLS 1.0

Open the Advanced Port Mapping Settings dialog by clicking the Options button in the Port Mapping dialog, and check ‘Enable auto-SSL detection’.  Set the SSL Version to TLS 1.x:



Because the settings in the Advanced Port Mapping Settings dialog affect all addresses and ports, the list of servers is left empty:



Scenario 7: Recording the traffic to 3 servers only: (SSL 3 version), (TLS 1.0 version), and (plain HTTP), with all the servers listening on port 443

The Port Mapping dialog should include four entries - a disabled entry for all servers, and a separate entry for each server, configured to listen on port 443 and the relevant SSL version for the server, as follows:



Scenario 8: Recording SSL 3 traffic to the server at, when you have a client certificate (PEM) file and its password

There are two options to choose from:

  • Install the client certificate (client_cer.pem)  on your machine (in the local certificate keystore) and choose it from the list of available client certificates during the recording
  • Use the Port Mapping dialog and define the client certificate there

The first option is applicable when the certificate should be installed anyway, and will result in the script using the certificate during the replay.


The second option is used when the PEM file is not installed, but is available as a file on the local machine. In this case the script needs to read and use the file during recording and replay.  Create a new entry for the server at, and configure the location and password of the client certificate:



Note that the dialog has a ‘Test SSL’ button which can be used to test the SSL connection with the certificate.


Scenario 9: Recording the scenario takes considerably more time than performing the scenario without recording

If the application doesn’t use SSL, you can record all the traffic using the so-called ‘direct’ connection mode.  VuGen’s default connection mode is called a ‘proxy’ mode, and as its name suggests, it uses a proxy in order to capture the network traffic between the client and the server (not to be confused with Proxy Recording in LoadRunner!). When no SSL is used, the ‘proxy’ mode can be substituted by the ‘direct’ mode, which allows a direct connection between the client and the servers.  The ‘direct’ mode is much less time consuming than the ‘proxy’ mode.  In order to enable the ‘direct’ mode, create a new entry for all of the connections, and set the ‘Record Type’ to ‘Direct’:





Summary: This post presents a number of common recording scenarios, and explains how they can be performed by correct configuration of the Port Mapping Dialog. I hope that we have achieved our goal of demonstrating the versatility and importance of the Port Mapping dialog.


You can download LoadRunner 11.50 here.



Let us know if you found this article useful by leaving a comment in the box below.


Thanks to Gennady for providing this article!


GauravR(anon) | ‎02-06-2014 11:55 AM

Thanks for the useful information in the post. I had some questions.


What is the purpose of WinINet level Recording? When can it be used? How is it different from Socket Level?


I tried to look into the Vugen Guide but didn't find much in it... or should i say didn't understand it.

HP Expert on ‎02-06-2014 12:15 PM - last edited on ‎02-06-2014 12:31 PM



Generally speaking, the WinInet recording is a Legacy feature used rather as a workaround.

It can become handy when the Default Socket recording is not working (tight SSL restriction, for example).

The Socket level recording records the network traffic, while the WiInet records only WiInet activities.

One of the huge WinInet limitations is the inability to record applications other than the InternetExplorer.


As the bottom line, our recommended recording mode is Socket level. WinInet should be only used as a workaround.



Gnanasekar(anon) | ‎02-19-2014 03:35 AM

Excellent article. Thank you

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Showing results for 
Search instead for 
Do you mean 
About the Author
Malcolm is a functional architect, focusing on best practices and methodologies across the software development lifecycle.

Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation