Digging into it, I identified the system as our newly installed Windows 7 host. This seemed a bit odd. Most of the dropped packets were to a single destination, 65.55.158.118.
Searching through the DNS logs, I found that the IP was only involved in a request for teredo.ipv6.microsoft.com. The picture below shows the result of the query, however the googleusercontent.com return is an error in the way DNSMASQ mixes the logs for simultaneous return records. So, there is only one domain to IP relationship between teredo.ipv6.microsoft.com and 65.55.158.118.
To see the activity of just the traffic to this host, I decided to graph the activity to IP address 65.55.158.118 across all of the datasets. This would show the interrelationship of DNS, firewall, and proxy resources over the last seven days. I used this query in my Splunk search:
65.55.158.118 earliest=-7d | fields sourcetype | timechart limit=0 span=1h count(sourcetype) by sourcetype
The columns only indicated DNS and firewall would be factors since no proxy logs matched. I clicked 'Show Report' at the upper-right and selected a line graph with a logrithmic aspect. Here are my results:
So, my new Windows 7 host commits nearly constant DNS resolutions to teredo.ipv6.microsoft.com, resolves to 65.55.158.118, then sends roughly nine times as much direct traffic to that IP to die at the firewall as it is apparently not proxy aware.
My understanding has been that Microsoft disabled Teredo Tunneling by default after Windows XP Service Pack 1 due to industry concerns about data control. This is confirmed by a TechNet article released in 2007. A separate post found at the Microsoft Answers site indicates for Windows 7, "Teredo is installed by default and enabled so that it remains in a standby mode and comes into action only when required." Apparently not since it makes queries ALL THE TIME.
Teredo-by-default remains a potential security and data-loss issue for companies, many of whom lack tools to analyze the 6to4 wrapped protocol for network intrusion detection, enforcing proxy use for regulatory compliance, or other purposes. Some analysis of the protocol has been undertaken, as indicated by this Internet Storm Center article about a year ago, and followed by an execellent analysis by Johannes Ullrich in May. However, this level of depth in monitoring this protocol is not packaged or attainable to most businesses today.
To address the issue, administrators not utilizing Teredo for their domain should disable it via Global Policy. For home users of Windows 7 and Vista, this article at Windows Seven Forums provides instructions to disable the service.
In the Windows menu search bar, type 'cmd.exe', but don't open it. Right-click cmd.exe and select 'Run as Administrator'. Click Yes if prompted to confirm running the program with elevated privileges. Now follow the commands indicated in the output below:
C:\Windows\system32>netsh
netsh>interface
netsh interface>teredo
netsh interface teredo>set state disabled
Ok.
netsh interface teredo>exit
C:\Windows\system32>
Reboot the system to have the setting take effect.