Windows 7 using wrong output IP adresses when multiple IP are configured to the same adapter

Question

I've added a second IPv4 address to a network adapter and Windows started to use this second IP as the default output address. Even the address beeing in a completely different subnet from the default gateway.

My default IP address is 169.254.1.38/24. Yes, we use the auto address assigment IP range, but this is a static configured IP address and our DHCP server would assign me the same IP if I change to DHCP configuration. My gateway is at 169.254.1.1.

I've added the 192.168.38.1/24 ip address using the 'advanced' button in the adapter properties. As soon as I close the dialog, Windows start using 192.168.38.1 as the output address when trying to reach the Internet. As our router is in another subnet it does not respond to the requests.

The output of route print is (output was in portuguese I've translated the labels:

...
IPv4 route table
===========================================================================
Active routes:
Network address            Mask         Gateway addr.      Interface   Cost
          0.0.0.0          0.0.0.0      169.254.1.1     192.168.38.1    266
...

And as soon as I remove the second IP, the Interface value of the route returns to 169.254.1.38 and everything goes back to normal.

Is there any way I can alter this route so it starts using the correct IP address? The route add command just accepts interfaces as parameters and not IP adresses.

I'm using Windows 7 64bit.

Solution 1

The IPv4 link-local subnet, as defined in RFC 3927, is always supposed to be 169.254/16 (Note: /16 not /24), and the "0" and "255" values in the third octet are reserved for when you're manually configuring an IPv4 link-local address. All the other values for the third octet are reserved for automatic self-assignment, not manual assignment. So if I were you, I'd change 169.254.1.38/24 to 169.254.0.38/16, and I'd change 169.254.1.1/24 to 169.254.0.1/16

If you have a DHCP server, you shouldn't be using link-local, you should be using an RFC 1918 private subnet (10/8, 172.16/12, or 192.168/16). So really, instead of just switching to the "0" or "255" third octet in the link-local subnet as I described above, you should probably just completely switch to an RFC 1918 private subnet and stop using the IPv4 link-local address space at all. I'm not sure that this has anything to do with your problem, but I thought you might like to know how to better follow the standards for the address spaces you're trying to use. Fixing this now might avoid some subtler problems later.

Be aware that since you're using RFC 3927 IPv4 link-local address space, your IP stack is probably using the "all subnets are local" behavior defined in RFC 3927. Because of the "all subnets are local" behavior of IPv4 link local addresses, it's perfectly fine to use an RFC 1918 private IP address like 192.168.38.1 to talk to an IPv4 link local IP address like 169.254.1.1 on the same broadcast domain (e.g. Ethernet LAN).

Solution 2

First, I would have done this with two network cards...much simpler.

I am just adding this as proof that you are not getting expected bahavior (I know it does not apply to Windows 7, but this type of stuff does not change often): "A single network interface card (NIC) configured with multiple IP addresses defined on different logical subnets will always use the first IP address defined in the TCP/IP configuration as its source address, regardless of the destination."

http://support.microsoft.com/kb/149399

I would check

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\

Then search through for your interface, and manually change the order of the IP addresses in the "IPAddress" key. I doubt it, but you may need to disable and reenable the interface.

Comments

[Vargas]

I'm not using RFC 3927, the entire company was configured using 169.254.1/24 a long time ago, and changing things is not that easy. If I change my IPs to 192.168/16 per example, it will work fine, but using 169.254.1/24 does not.

[Vargas]

I found that Windows will not use the first IP in the "IPAddress" key if the first one is in the RFC 3927 (169.254/16) range (and the second one doesn't). This probabably by design in Windows 7 but I wasn't aware of it. Windows XP works fine.

[Spiff]

@Vargas The fact that it works fine when you fix the subnet mask is evidence that your IP stack is invoking its RFC 3927-related code paths. The 169.254.x.x addresses are reserved for RFC 3927 IPv4 link-local addressing. Modern IP stacks are written with that in mind. If you use those addresses, your IP stack's RFC 3927 code will automatically kick in. That's why I'm advising you to use address space correctly. RFC 1918's subnets are the right ones to use for what you're doing, not RFC 3927. 169.254.x.x is specially-handled, much like 0.x.x.x and 127.x.x.x and 224.x.x.x and 255.x.x.x.