IP Spoofing Alert from APIPA Address in Forefront TMG 2010
Security administrators may encounter the following IP spoofing alert on their Forefront TMG 2010 firewall:
Alert: IP Spoofing Description: Forefront TMG 2010 detected a possible spoof attack from the IP address 169.254.x.x. A spoof attack occurs when an IP address that is not reachable through the network adapter on which the packet was received. If logging for dropped packets is enabled, you can view the details of this attack in the firewall log in Forefront TMG 2010 log viewer. If the IP address belongs to a VPN client, this event may be ignored.
This alert occurs because the Forefront TMG 2010 firewall received a packet on its internal network interface from a client (server, workstation, or other host) that did not have a statically assigned IP address and was not able to obtain one from DHCP, so the client selected an IP address from the Automatic Private IP Address Assignment (APIPA) address range defined in RFC 3927.
You can safely ignore this alert, or you can resolve the issue by adding the APIPA reserved network 169.254.0.0/16 to the Internal network definition. This can be accomplished by opening the Forefront TMG 2010 management console and highlighting the Networking node in the navigation tree, then right-clicking the Internal network, selecting the Addresses tab, then clicking the Add Private button and choosing the address range 169.254.0.0 – 169.254.255.255.
Note: It is possible to resolve this issue by disabling alerts for IP spoofing attempts. However, this is considered bad security practice and is strongly discouraged.
You may recall from an earlier blog post I indicated that the best way to configure the Internal network definition in Forefront TMG 2010 is to choose the Add Adapter option. This still remains true. However, this is one of those rare cases in which you’ll want add an additional network address space to your Internal network definition to reduce the volume of IP spoofing alerts being raised by the Forefront TMG 2010 firewall.
The one side effect to implementing this change is that you will now receive a Configuration error alert informing you that your Internal network does not correlate with the network adapters that belong to it.
Essentially you have traded one annoying alert for another. However, the noise generated by IP spoofing alerts from clients with APIPA IP addresses might make this tradeoff worthwhile. In addition, it is much safer to disable the configuration error alert than it is the IP spoofing alert.
Connect
Richard Hicks' Forefront TMG Blog 
I think you can use a fake static route too. WIth the static route, no configuration Error message. (It’s just a thought, i haven’t test!)
Yes, you can add a fake static route for the 169.254.0.0/16 network and you wouldn’t receive the configuration error alert. I’ve done this in the past, but it isn’t something I’m comfortable with recommending others do (which is why I didn’t suggest it in the main text of the article). 🙂
Thank you thank you thank you! This was bugging the life out of me. The “fix” is obvious when you know how. 😀
Glad you found the post informative and helpful! 🙂
Hi Richard,
We are using TMG 2010 with exchange server 2003. Could you please help me to know how can I stop spoofing using TMG
Email flow – External Email -> TMG 2010 -> Message Labs -> Exchange Server 2003
One of the mailbox is keep on receiving NDR from Postmaster stating the email is not delivered for the emails which was not sent by user. while investigating in Message Labs it says the emails are from TMG to Message Labs having from address as internal user and email sent to external invalid email addresses. Not sure how to find the source IP which is relaying those spoofing emails.
How to identify the external source which is sending these kind of emails and how to stop it. Please advice.
Not exactly sure what the problem is, but you might have to dig through the logs and correlate the times to find out more about this.
The information in this article does not work if your network card receiving the 169 address is on a different network subnet (i.e. 192.168.x.x, 172.16.x.x). [having been there and tried it myself 🙂 ]
The network card has to be able to receive that 169 communication or you’ll still get the spoof, regardless of the addition of the 169 address range in the internal network.
It does seem like adding the route would fix it–per other commenters. But I’m not comfortable with that either.
I’m not sure I follow you here, Mark. Your TMG firewall will always have an IP address on a different subnet from the 169.254.0.0/16 network, so following the steps outlined in this article should prevent the spoofing alert, as described.
Just a heads up, it STILL gives me the alert even with 169.x.x.x added to internal network
Even after adding the 169.245.0.0/16 subnet to Forefront TMG 2010’s internal network definition?