Highlighted

Making Virtual IP as source IP on Windows 2008 R2 node

 

We are running SFHA v5.1 for Windows 2008 R2 and we would like the floating virtual IP assigned to resource group to the be the source IP of the node instead of the default IP assigned to the interface. I'm a little fuzzy on how Windows chooses which IP is the source IP if there are multiple IP's assigned to an interface, but I was wondering if there is any configuration setting that can be chosen within SF.

 

This is important because the firewall team only wants to allow through the VIP of the resource group.

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

Hi David, I'm not sure that

Hi David,

I'm not sure that KB is the same issue that you are describing.  The KB is talking about having multiple DNS entries for a given server and you are describing firewall configuration concerns with having multiple firewall rules for different IPs.

We have had customers with firewall concerns such as yours and they either make changes to the IPs used as I have described or they enter a rule for each IP used to get around the issue with the Microsoft TCP/IP stack picking the source IP for outbound packets.

I have not seen any issues with the "route -p add" and the routing table during cluster failover. 

Thanks,

Wally

View solution in original post

3 Replies
Highlighted

Hi David, The source IP of

Hi David,

The source IP of all outbound packets is determined by the Microsoft TCP/IP stack.  SFW-HA has no control of what the source IP of outbound packets will be.

With that said, depending on your configuration there might be some things that you can do to help influence what IP address Microsoft uses. 

Here is my basic understanding of how the Microsoft TCP/IP stack selects the source IP for outbound packets.  All outbound packets are tagged with the IP address that corrosponds to the IP address with the lowest host ID.  In other words given a server with two IP addresses 10.10.10.10 and 10.10.10.11 both using subnet 255.255.255.0 all outbound traffic should be stamped with 10.10.10.10 because the last octet 10 is lower than 11.

If you have only one service group with 1 IP address then it is simply a matter of selecting the correct virtual IP address.  From the example above, all you have to do is select the right virtual IP of 10.10.10.10 and physical/admin IP of 10.10.10.11 and the source will be 10.10.10.10.  With the other nodes in the cluster you just have to select a physical/admin IP of say 10.10.10.12 to make the virtual IP work as the source on all servers.

Its been a while since I've tried this and if memory serves me right, Microsoft changes how they determined the source with one of their windows releases.  It might be the IP with the highest host ID and not the lowest host ID.  I would recommend testing to be sure.

The other problem that you are going to face is that if you firewall admins only put in a rule to allow the virtual IP only then if the service group is not online on the node then you cannot access it remotely.  And if the service group is not online at all then you cannot access the cluster remotely.  This is why I recommend adding firewall rules for all physical and virtual IPs used in the cluster.  If you are using multiple service groups with multiple virtual IPs that can be online on the same server then you have to add multiple firewall rules and putting in 1 more rule for each physical server really is not that much more work.

Thanks,

Wally

Highlighted

Hi Wally,   Thanks for the

Hi Wally,

 

Thanks for the reply. Only the active node which contains the service group needs to make an outbound connection, so the network folks really want to restrict to the associated virtual IP.

Here is a "solution" but I don't see how it can be implemented into the cluster software:

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

I'm just surprised that this issue does not come up more often.

One other thing we are seeing is we use "route -p add" to add a static route cluster which seems to be affected when the cluster fails over (it is no longer usable), the only way we fix the issue is by deleting and re-adding the route.

Best regards,

Highlighted
Accepted Solution!

Hi David, I'm not sure that

Hi David,

I'm not sure that KB is the same issue that you are describing.  The KB is talking about having multiple DNS entries for a given server and you are describing firewall configuration concerns with having multiple firewall rules for different IPs.

We have had customers with firewall concerns such as yours and they either make changes to the IPs used as I have described or they enter a rule for each IP used to get around the issue with the Microsoft TCP/IP stack picking the source IP for outbound packets.

I have not seen any issues with the "route -p add" and the routing table during cluster failover. 

Thanks,

Wally

View solution in original post