Chris Blankenship's Ramblings

The other day I ran into a problem when I tried to configure my server to listen on port 443 with a specific IP address instead of the ‘All Unassigned’ option.  This server had two IP addresses (192.168.1.10 and 192.168.1.11) and I planned on having 192.168.1.10:443 listen for web traffic, and 192.168.1.11:443 listen for SSH (check out why I wanted to use 443 for SSH on my previous article.) 

After configuring the IIS Web Site bindings with 192.168.1.10:443 I tried to start up the SSH Server configured with 192.168.1.11:443.  Expecting this configuration to work I was frustrated to find that the SSH Server was unable to start, indicating the port was unavailable.  Using Netstat I could see a binding listed as “0.0.0.0:443” even though I had specifically instructed IIS with 192.168.1.10:443.

This didn’t make sense to me until I came across some information regarding Socket Pooling.  Up until now I hadn’t really dealt with Socket Pooling so I needed to learn more.  I found some information in a Technet article titled IIS 5.0 Technical Overview that described Socket Pooling:

In IIS4, you could bind different Web sites to different IP addresses. Sites did not share sockets, but each site on a unique IP address had several sockets. These sockets are created when the site starts, and they consume significant non-paged memory (RAM). This memory consumption limits the number of sites bound to IP addresses that can be created on a single machine.

For IIS 5.0, this process has been modified so that sites bound to different IP addresses, but sharing the same port number, share the same set of sockets.

It seems that with Socket Pooling enabled you would expect that all IP addresses on a server would be bound to a specific port (referred to as a socket) and without breaking the Socket Pool you would not be able to separate the port binding between IP addresses.

In order to achieve my objective of assigning different IP:PORT bindings I would need to disable the Socket Pooling on my server.  To accomplish this I need to use the NETSH command  to instruct HTTP to only bind to the 192.168.1.10 IP address.  Here is the syntax I use:

netsh http add iplisten ipaddress=192.168.1.10

After running the NETSH command and restarting the IIS services I can verify this setting has been applied with the NETSH and NETSTAT command:

C:\>netsh http show iplisten

IP addresses present in the IP listen list:
-------------------------------------------
    192.168.1.10

C:\>netstat -na | find ":443"

  TCP  192.168.1.25:443  0.0.0.0:0  LISTENING

This all starts to make sense but still leaves a bad taste in my mouth.  For instance why would the IIS Management Console pretend to be honoring your specific IP:PORT assignment in the Web Site Bindings even if Socket Pooling is enabled?  And why can’t I find much documentation about how to disable the Socket Pooling with the NETSH command?

Hopefully this will be helpful to others who are faced with a similar task of separating port bindings across different IP addresses.