HTTP Listener configuration
Service Virtualization updates port settings for HTTP/HTTPS communication according to the Service Virtualization default configuration, during installation of the Designer, or when the Server is run for the first time. When you create or modify Service Virtualization agent configurations, Service Virtualization automatically updates these settings. Checking the settings manually may be useful for troubleshooting purposes.
To change the automatic configuration settings, see Windows firewall and TCP port configuration.
Default settings are defined for the Service Virtualization Server, Designer, and Service Virtualization Management. Ports are also defined for the product demos, which are not required for anything else.
The default configuration is as follows:
|Product||Detail||Reserved URL||Protocol||Certificate Binding|
|Designer||HTTP Gateway Agent||http://+:7200/||HTTP||No|
|HTTP Proxy Agent||http://+:7201/||HTTP||No|
|HTTPS Gateway Agent||https://+:7205/||HTTPS||Yes|
|Server||HTTP Gateway Agent||http://+:6070/||HTTP||No|
|HTTP Proxy Agent||http://+:6071/||HTTP||No|
|HTTPS Gateway Agent||https://+:6075/||HTTPS||Yes|
|Service Virtualization Management||Web interface||https://*:6086/||HTTPS||Yes|
|Demos* (installed with Designer)||Not specific||http://+:8101/||HTTP||No|
* Only URL Reservations are created for ports used by the demo projects to allow you to start the demos. Windows Firewall is not opened for the ports used by the demos for security reasons. As a result, you can only call demos from the local machine.
Checking the settings manually may be useful for troubleshooting, especially if Windows User Access Control (UAC) is enabled.
You can use the Windows
netsh command line tool to check the port settings used for HTTP communication. For older Windows operating systems, use the
To show ACLs on all ports:
netsh http show urlacl
To show SSL certificate bindings on all ports:
netsh http show sslcert
To show ACLs on a specific port for HTTP:
netsh http show urlacl http://+:PortNumber/
To show ACLs on a specific port for HTTPS:
netsh http show urlacl https://+:PortNumber/
To show SSL certificate binding on a specific port:
netsh http show sslcert ipport=0.0.0.0:PortNumber
where PortNumber is the TCP port number.
You can use the Windows
netstat command line tool to list protocol statistics and network connection information. For example, you can check that the Service Virtualization agents are listening on their assigned ports to determine that the virtual service endpoints are functioning. The statistics can also be useful to troubleshoot port conflicts that might require you to reconfigure agent port assignments.
To list all ports on the local machine on which services are listening:
netstat -a | find /i "listening"
The output lists all listening services. The ports used by the Service Virtualization Server are as follows:
TCP [::]:6070 hostname:0 LISTENING
TCP [::]:6071 hostname:0 LISTENING
TCP [::]:6075 hostname:0 LISTENING
TCP [::]:6076 hostname:0 LISTENING
TCP [::]:6085 hostname:0 LISTENING
TCP [::]:6088 hostname:0 LISTENING
The open connection between the machine running the real service and the machine running Service Virtualization is essential for successful message recording. The connectivity can be blocked and checking it with a simple tool can save you time. For example, for a Service Virtualization agent listening on a port, you can check the connectivity to this port using telnet.
Note: The telnet client may not be enabled in Windows. You can enable it using Windows Control Panel.
To check connectivity from the machine where the real service is running to the machine where Service Virtualization is running, type the following at a command prompt:
telnet ServerName PortNumber
ServerNameis the machine where Service Virtualization is running
PortNumberis the TCP port number of the agent for requests
The result is one of the following:
- A connection failure - a message is displayed.
- A successful connection - the command window is cleared and displays only a blinking cursor. If you enter Crtl^C, the connection is closed and a message is displayed.
Successful connection indicates that the communication should be open and the recording of real service messages by Service Virtualization should work. However, if it still does not work, this indicates that the problem is not caused by firewall or port settings. The problem is more likely with the virtual service configuration.
A failed connection via telnet indicates that the communication is blocked in transit. The first thing to do is to check Windows Firewall settings and TCP port configurations.
If everything is set correctly but the connection is still blocked, the problem is likely caused by the infrastructure between the machines.