Ok. Let me set up the sittuation. Configuration:1 - Windows 2008 / IIS. 1 Nic - 3 Ip's, running IPv4. IPv6 is disabled. Primary Nic address 172.16.26.56. Other IP's bound are - 172.16.26.66 and 172.16.26.83. This server is in a DMZ and is locked down with a firewall. Firewall services on the server is Off. The other 2 IPs are used for IIS websites. Each website attaches to a database server outside the DMZ. With all our windows 2003 servers we would open a port from the IIS servers primary IP to the SQL servers IP and that worked. Now with the new windows 2008 its trying to send outthe traffic from a secondary IP (172.16.26.66)and not the primary. This is a nightmare with our network adminand trying to figure out what IP the servers are going to send the traffic out of. So the question is "how do i make the windows 2008 server use the primary IP (172.16.26.56) instead of the .66 address." And maybe explain why this is happening.Thank you!

Have you checked your NIC bindings (in which order): Open Network Connections Press ALT key (dont hold, another list of menus will show up) Click advanced then click Advanced Settings Click the adapters and bindings tab, then under connections, click the connection you want to modify Then under the Binding for connection, you can move the protocol up or down for the connection you have selected at the top Certifications: MCSA 2003 MCSE 2003

hpbigfoot, This is definitely not an interface binding issue. I can repro this, and like I believe you implied, we both only have a single interface, and if you correctly disable IPv6, IPv4 is automatically at the top of the list. Even if this is the case, you can still repro the problem. I cannot explain why this happens, or give you a fix, but I can validate that it does happen. I tested this on fresh, patched/un-patched, images of server 2008 SE and EE, and found the problem all around. I tried fully disabling IPv6 per http://support.microsoft.com/kb/929852with no change. I can tell you from 2003 that the IP address that gets added in the "Interface" collum of the local routing table (seen with netstat -r) is the IP that will go out in the packets' source IP, and this seems to remain true in 2008. You will notice that it is not always the primary IP that gets added to the routing table, that this is the one that is marked on the outgoing packets. I went rounds and rounds hoping that changing things in the registry would help things, with no luck. I ended up taking a procmon of the route.exe to see how the local routing table info was built. I tried modifying some of the low hanging fruit with no luck either. I cannot explain why this is happening, nor could I find any documentation to this end. All I can add here is validation that it does, and simple repro steps. Statically assign 10.1.1.2 to an interface. Under the advanced properties under TCPIP on the interface add 10.1.1.1 as a secondary IP. Apply the settings. View the local routing table using route print You will see that 10.1.1.1 is the exit interface listed for packets. If you trace on the wire you will see packets sourced from 10.1.1.1, instead of the primary address 10.1.1.2 Don't forget to give credit where credit is due, vote this as helpful if it helped you.

To investigate the issue more I would suggest to create a network capture with Network Monitor or Whireshark. See If you can see some strange activities there.Also a NetDiag log would be useful. However to be able to run NetDiag, you must copy it from a Windows 2003 Server to a Windows Server 2008 server. Certifications: MCSA 2003 MCSE 2003

I am currently at a 2008 IIS class and asked the question there. They brought in other instructorsand so far they don't have an answer either. Still searching...

http://blogs.technet.com/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspxthis post might be helpful

I know this reply is a bit dated now, but I wanted to chime in that the above post helps identify the problem, but using WireShark shows with Windows Server 2008 Enterprise running with SP2 installed, the server does not follow RFC3484 to the letter. I have a box that is experiencing the same issue described above, but the IP address used changes as you add more IP addresses to the NIC. For my scenario, we host IIS sites on this server. We started with 5 IP addresses, 1 primary IP that admins have rights to remote into the box and which is also used for accessing our secure database. Only this primary IP has the proper firewall holes punched to allow access. The other 4 addresses are used for the IIS sites. These IIS IP addresses are restricted to port 80 and 443 access and to different intranet subnets. They are isolated by their own App Pools, restricted by different resource account identities, and their access to the databases are restricted based on these settings. So, initially everything was working fine. Then we added 3 more IPs to the NIC for new IIS sites. That is when the primary IP address is no longer used for the source IP for database connectivity. Following RFC3484, (we are only using IPv4) the longest matching prefix should be used, but the server is not using that calculated IP. Below is the partial addresses to describe what is happening: x.x.15.254 - gateway address x.x.15.45 - primary IP x.x.15.88 - site #1 x.x.15.89 - site #2 x.x.15.98 - site #3 x.x.15.99 - site #4 Using the above list only, x.x.15.45 was used for outbound database traffic. That is the least matching prefix. For the next set of addresses added: x.x.15.133 - site #5 x.x.15.146 - site #6 x.x.15.151 - site #7 Now, x.x.15.133 is being used. This is what was discovered using WireShark. This address is not the longest matching prefix. Has anyone discovered a way for force the primary IP address to be used? Thanks. Dave

Working with another technician today trying to get around this issue, we stumbled upon this article which might be helpful: http://support.microsoft.com/kb/975808

Dave, Curious to see if you have applied the above hotfix (975808) and if so, did it resolve the issue? After adding additional IPs to a NIC we are experiencing an (almost) identical issue. I say "almost" in that it seems the default IP used for outbound communication appears to be the "lowest numeric" value IP address (all IP's are in a /24 subnet). We are also running Win 2k8 Enterprise, SP2. Jim

Jim, Yes the hotfix works for us, but it is not as clean as just applying the patch. Once the hotfix was applied and we restarted the server, we had to remove all the IP addresses from the NIC except the primary IP address, and then add the web site IP addresses one at a time using the Netsh command outlined in the hotfix documentation. Then when you add the bindings for the specific IP to the IIS7 site, you need to enter the IP address in the dropdown box. It does not show up in the dropdown list anymore. Once you restart the "World Wide Web Publishing Service" everything started to operate correctly. So, the fix works for us. Dave

Thanks for the detailed response Dave.After applying the 975808 hotfix (per the recommendation of MS support), we too have noticed similar behavior in that the IP's do not show in the bindings lists.Aside from that, all appears to be well.Jim

You may find this useful: http://blogs.technet.com/b/networking/archive/2009/04/24/source-ip-address-selection-on-a-multi-homed-windows-computer.aspx Except: Windows Vista and later are based on the strong host model. In the strong host model, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. Also the concept of a primary IP address does not exist.

Has there been a fix for windows server 2008 R2 yet ? Been waiting on this for a while, I had to use ippools to get our setup here to work.

Just called MS and they wanted to use one of our partner support incidents.....cheek What were they thinking about.... A:) They thought was a good idea to dymanically choose the source based on destination or gateway address B:) I can't beleive they made this the default behaviour C:) They haven't released a hotfix for Windows 2008 R2 D:) They want us to pay for their incompetence OK rant over.....

Have been working a whole day on this issue on my new windows server 2008. Not happy. Reasons are well explained by previous posts. It is really a BIG FAT BUG. And the mentioned hotfix (975808) is not applicable to my version. Not happy at all. Finally found that if I set all other IP addresses's subnet marsk(e.g. 255.255.0.0) different from the one(255.255.255.0) of primary IP address, SOME programs outbound traffic will be fixed to primary IP while the inbound traffic of all IP addresses is not affected. It just fixes my problem (mainly SMTP relay issue). Good luck!

Spoke to MS support, they acknowledge it is their mistake and the fix is tenatively scheduled to be released with SP1. No time was given when though. This is a MAJOR problem which has cost us a lot of time; can't believe it got pass the testing stage. Wayne

The 2008 R2 SP1 beta is out. Anyone want to test and see if it fixes our IP problem? http://technet.microsoft.com/en-us/evalcenter/ff183870.aspx

I've been troubleshooting this for ages, was starting to wonder if I was going mad. I will try the patch and report back.

Ah, as someone else points out, this is only for non-R2 editions. That's unfortunate.

I can't believe there is still no R2 fix for this yet. Very disappointing.

Bump

If anyone is not aware, here is the fix released for R2. http://support.microsoft.com/kb/2386184/

I know this is old, but I was wondering if someone could help me. I installed this hotfix and cannot get the command line to work. Here's the syntax I'm using netsh int ipv4 add address “Local Area Connection” 1.1.1.1 255.255.255.0 skipassource=true I get an error saying skipassource is not a valid argument for this command. Any ideas? - Michael