Set Main Source IP Address in Windows Server 2008

Well, one day your company decides to put in place one website. This website must have SSL authentication (also known as HTTPS), and that's OK. It should'n be so difficult, right?

Wrong. I tried to do things right the first time, so I tried to analyze the situation. I had:



So, let's check how to add a new domain, with a new certificate on IIS 7.5 and Windows Server 2008 R2!
Adding a new website is straightforward, something like right click-> new website.
To add HTTPS it's a bit different. You have to add what's called a binding to the website and assign one of the certificate you loaded into IIS. To quote words from this blog (Chris's Blog - Just weedin around Microsoft) :
You see, Websites have something called Server Bindings which represent the underlying address, port, and potentially a host header that your Website is accessed using. 
The matter of this post however is not to teach you how to create a website on IIS, but to complain about Microsoft. No, wait, it was about how to manage HTTPS on a windows web server, in case you have multiple ip addresses on the same interface.

Well, anyway after a short research on Mother Google, I found out that on Windows Server 2008 R2 you cannot host websites in https from different domains on the same IP and port (eg. you cannot host both https:// www.examplesite.com and https://www.siteexample.com on 192.168.1.20:443). The reason, as far as I understood, regards the IIS version: IIS 7 does not support Server Name Indication (Wiki - Server_Name_Indication), a slight change in the TLS negotiation . (As a side note, IIS 8, provided with Windows Server 2012, supports it).

The only two ways in Windows Server 2008 are:

In my opinion to change listening port is not an elegant solution and causes a lot of trouble with natting and routing, but it's anyway valid; I chose to add an IP address to the NIC (Network Interface Controller). I picked up a random free IP address of the subnet, and then confirmed. Then, the disaster.

Services, websites, back-end jobs, all of them stopped. Problem is, we didn't found out until about 1 am, when the number of reports of failing jobs was becoming unbearably great. 
What caused all of this was obviously the new IP address. But how? A little digging found out that our firewall was blocking a lot of requests from the new address, and request to internal services limited by IP. Why is Windows using that as a source address? Can't I set a static source address?

Well, in Windows Server 2003 it seems you could, but from 2008 you cannot any more. It uses some other logic, as better explained here : Technet - Networking Blog - Source IP address selection on a Multi-Homed Windows Computer .
To make it simple, when you request a service (eg. a website) with some IP, Windows examines the routing table to pick up the best interface from which to send the request. Then, "within" the interface, it chooses the best IP address to use as a source, using a set of rules. This set of rules is RFC 3484 . These "rules" apply only to IPv6, but Microsoft chose to use them even for IPv4: 

Windows Source IP V4 address selection: 
Rule 1 Prefer same address (applies) 
Rule 2 Prefer appropriate scope (applies) 
Rule 3 Avoid deprecated addresses (applies) 
Rule 4 - Prefer home addresses - does not apply to IP v4 
Rule 5 Prefer outgoing Interfaces (applies) 
Rule 6 Prefer matching label - does not apply to IP v4 
Rule 7 Prefer public addresses - does not apply to IP v4 
Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!) 
"If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if 
CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. " 
This says that the IP with the most high order bits that match the destination of 
the next hop will be used. 
Note: Rule 8 - Use longest matching Prefix is similar to rule 8a except the match 
is with the destination IP address rather than the next hop IP address.
Well Well Well... Look at rule 8a...What does it mean?
Consider the IP addresses in binary:
11000000 10101000 00000001 00001110 = 192.168.1.14 (Bits matching the gateway = 25)
11000000 10101000 00000001 01000100 = 192.168.1.68 (Bits matching the gateway = 26)
11000000 10101000 00000001 01111111 = 192.168.1.127
For people in what I think will be the most common situation, this means that Windows will use as source address the IP "nearer" to  the default gateway. The nex example is similar to my situation:
- 192.168.1.10 - website1
- 192.168.1.12 - website2
- 192.168.1.14 - back-end jobs (which uses several internal and external services)
- 192.168.1.80 - new website
- 192.168.1.254 - default gateway

Before adding "192.168.1.80", 192.168.1.14 was the default source address (because it was the nearer to the GW!) . Immediatly after adding the new address, THAT (192.168.1.80) became the new defaut source address! Because many services were available only by IP address, our server could'n reach them any more.

What's the solution then? Well, in my situation, I changed the new IP in 192.168.1.13 (a really horrible solution, but good for the emergency) and everything immediatly was fine again.

A "good" solution could be to download this hotfix, then use the following command to add the secondary IP address:
netsh int ipv4 add address "Local Area Connection" 192.168.1.80/24 SkipAsSource=true
The flag SkipAsSource  is quite the opposite of what I wanted: the address with this flag won't be used as source IP. I was searching for a way to set an IP as default; well, for low numbers of IPs, I can create one IP to use as source, and all the others with the above command for other uses.

But this solution is good only in the case you have to add new addresses. For the ones already active, you have to delete and recreate with the right flag. Which, in a production environment, could be a BIG problem, both technical and political.

Thanks a lot to www.confusedamused.com who brought me in the right direction to understand the problem!

Labels: