One of our client’s servers required VisualSVN to be hosted with a new site that required SSL. First, we added a second IP to the server (IP #2) and configured the new SSL cert & IIS bindings. Second, we went into the VisualSVN Network panel (Right-click VisualSVN Server –> Properties –> Network tab) and configured VisualSVN to listen to IP #1.
We found that IIS, by default, listens to all HTTPS traffic on all IPs causing a conflict with VisualSVN. A post on ServerFault.com suggested that we try to override IIS’s default by manually adding the IP through netsh. We ran the netsh command to add our new IP and Voila! VisualSVN responded to HTTPS requests on IP #1, and our new site was responding to HTTPS requests on IP #2.
All good right? Not really. By adding IP #2 through netsh we effectively told IIS to listen to IP #2, however, IIS was now ONLY listening to IP #2. (VisualSVN was responding to IP #1 because it’s a standalone service and not run through IIS.) All of our existing sites using IP #1 were returning HTTP 502 errors.
The Solution: We added both IP #1 and IP #2 through netsh. After doing so, we are able to get VisualSVN to run on IP #1, port 443, existing sites on IP #1, port 80 and new HTTPS site on IP #2, port 443.
I am unclear on why the netsh command was needed in the first place. Our solution was to manually tell IIS to listen to all IPs–shouldn’t that be the same as the default behavior?
