TMG sources outgoing packets with Secondary IP addresses
Hello Everyone! We’ve seen a few cases lately dealing with TMG servers sourcing outgoing packets with secondary IP addresses that have been added to the NICs. This could cause issues in communications between nodes or possibly other issues. One such example that I have seen come across is where a customer had a TMG server being utilized as an internal firewall behind a 3rd party Edge firewall. Clients were utilizing the TMG server as their proxy server. When the http requests left the external interface of the TMG server the packets were sourced with a secondary IP address of the External NIC on the TMG instead of the primary address of that NIC. When the Edge firewall received the packets it dropped them because its rules were configured to only allow packets out when sourced with the primary IP address of the TMG’s external interface. This of course broke internet connectivity for all internal clients.
The question at hand is… “Why is the TMG server sourcing packets with a secondary address instead of the primary address of the NIC?”
The answer to that question deals with the differentiation between the Network Stack in Server 2008 and above and Server 2003 and below. Server 2003\XP and below were based off the Weak Host Model. Basically, in a Weak Host Model the primary address of the adapter with a route that most closely matches the target IP address is used as the Source IP Address.
In server 2008\Vista and above we re-architected the Network stack. It is based on the Strong Host Model. In the Strong Host Model the concept of a Primary IP Address doesn’t exist. To determine the IP address that is utilized it looks at the routing table to decide the proper NIC to utilize, then uses the process defined in RFC 3484 to choose the source IP for outbound packets. Here is a basic breakdown of how the windows implementation of RFC 3484 chooses an IP address:
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.
For example, use the following addresses as an example of choosing the longest matching prefix:
TMG Servers External IP Addresses:
192.168.1.14/24
&
192.168.1.68/24
Default Gateway:
192.168.1.127
Convert these addresses into binary:
192.168.1.14 = 11000000 10101000 00000001 00001110
192.168.1.68 = 11000000 10101000 00000001 01000100
192.168.1.127 = 11000000 10101000 00000001 01111111
The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. This would cause the server to utilize what was originally defined as the “secondary” as the Source IP address of outgoing packets.
*For more information on RFC 3484 please refer to the following link: http://www.ietf.org/rfc/rfc3484.txt . Please note that IPv6 is referenced in RFC. Windows utilize the same process for IPv4 sourcing.
You can also review the following TechNet article for supported document details on the above information:
The functionality for source IP address selection in Windows Server 2008 and in Windows Vista differs from the corresponding functionality in earlier versions of Windows
http://support.microsoft.com/kb/969029
So now we know why your TMG server may be sourcing your packets with what you call your “Secondary IP Address”. It isn’t TMG at all. It is the default behavior of the server itself. Your server version is Server 2008 or above. The question is…
“Can I configure my Server 2008 or above in a way that it will only utilize the first IP address as a Source address?”
The answer to that is YES! There is actually a Netsh command that can be utilized to add IP addresses. In that command you use the “SkipAsSource” flag and it will no longer use the IP address you are adding as a Source IP Address. This means that you will have to temporarily remove the IP Address you are having the issues with then re-add them utilizing the Netsh command (This means you will have to have a maintenance window!). Here are examples of the command lines you will use:
Server 2008:
Netsh int ipv4 add address <Interface Name> <ip address> <subnet mask> skipassource=true
Server 2008 R2:
Netsh int ipv4 add address <Interface Name> <ip address> skipassource=true
**
* For details and prerequisites to utilize these commands please refer to the following articles:
All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2
http://support.microsoft.com/default.aspx?scid=kb;EN-US;975808
IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/default.aspx?scid=kb;en-US;2386184
Keep in mind that I gave only one specific example where this may be causing an issue. There may be other problems you run into where the Netsh entry I listed may help you out. No telling… it may not even be on your TMG servers. Maybe you see the issue on your UAG servers, or any other server for that fact.
I hope the information provided helps out!
Author
Brett Crane - Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team
Reviewer
Richard Barker - Sr Security Support Escalation Engineer, Microsoft CTS Forefront Security Edge Team