The core TMG behavior (which is the same on ISA) for handling spoofed packets is well known. Basically, if the IP address belongs to the internal network and it is received on the external interface, it is expected that the packet will be dropped. By definition, the intrusion detection system on TMG will do the following:
Inspects every packet received by a network adapter installed on the Forefront TMG server to determine whether its source IP address is valid for the network adapter at which it arrived. An IP address is considered valid for a specific network adapter if both the following conditions are true:
· The IP address is included in the IP address ranges assigned to the network of the network adapter through which it was received.
· The routing table indicates that traffic destined to that address can be routed through a network adapter belonging to that network.
If the source IP address of a packet is not considered valid, Forefront TMG drops the packet and generates an event that can trigger an IP Spoofing alert.
Note: if you to the logs for this traffic, you will see that it drops the packet for the following reason: FWX_E_FWE_SPOOFING_PACKET_DROPPED.
When you receive spoofing error, the first action that you should take is to make sure that your network definition is correct. In other words, make sure that the source address (in this case 172.16.0.2) does not belong to your internal network. For this particular example that we are using on this post, TMG didn’t have this range as part of the internal network as shown below:
Notice that we have internal, external and also the 10.80.80.0/24 network, which is the VPN Client network, but 172.16.0.0/16 is not part of the internal network. So, why TMG is blocking the traffic as spoof?
The reason why this happens is because TMG analyzes the source IP of the packet and verify if this network is reachable via external interface (where it was received), if it is not then it interprets this traffic as spoofed. A snip from the lower level TMG tracing shows the following:
ERROR:GetBestRoute2(ip=172.16.0.2) failed 0xc000023c(STATUS_NETWORK_UNREACHABLE) Info:recv packet will be considered spoofed, reason : source address not routable thru recv interface Warning:Dropping packet - FWE_SPOOFING Info:source=172.16.0.2:49177 dest=192.168.0.30:443 protocol=6 action =DROP Info:Filter hook denied the packet Info:Stopping inspection actions! We did not get a permit
This problem was fixed by adding a default gateway on the external network of TMG. If you can’t add (for some network infrastructure reason) a default gateway on the external adapter of TMG, you will need to manually add a route to the network that it is getting dropped as spoofed so TMG knows how to get there.
This post explains a scenario where a missing element on the configuration (default gateway on the external interface) caused legitimate traffic to be denied as spoofed. Keep in mind those rules of thumb while configuring TMG networks so that you can avoid issues of this nature.
Author Yuri Diogenes Sr. Security Support Escalation Engineer Microsoft CSS Forefront Security Edge Team
Technical Reviewers Mohit Kumar Sr. Security Support Escalation Engineer Microsoft CSS Forefront Security Edge Team
Thomas Detzner Escalation Engineer Microsoft CSS Forefront Security Edge Team
Is there a common scenario that will not have default gateway in the external card?
Hi, this doesn't work in my environment. I already have default gateway on my external adapter.
tnx a LOT!
Thanks, does this applies also for internal scenario?
Hi Ori Yosefi,
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.
I confirm Nik's case
Our TMG has the default gateway address on the external network interface, and the route for external network as well, but this issue is still pops up.
I had a similar issue, just created the new route and designated the gateway on the LAN card and that was it.
Great Info. I was able to resolve similar problem by understanding the concept described here. I had internal traffic from diferent vlan onto TMG which was being treated as spoofed too. Adding range into internal network as well as adding network topology
route on tmg for that range/network did the trick. Thanks