Understanding a scenario where TMG drops the packet as spoofed even when the source IP doesn’t belong to the internal network

Understanding a scenario where TMG drops the packet as spoofed even when the source IP doesn’t belong to the internal network

  • Comments 7
  • Likes

1. Introduction

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.

From: http://technet.microsoft.com/en-us/library/cc995155.aspx

This post describes a scenario where the external user was trying to access OWA published through TMG 2010 and the request was timing out. From the TMG side, it was possible to see that the traffic was getting denied as spoofed, as shown in the log below:

image

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.

2. Troubleshooting

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:

image

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.

3. Conclusion

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

Comments
  • 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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment