TCP flooding when switching from a wireless to a wired connection

I've been having this problem for over a month now.  Periodically I see 10 to 15 times the normal traffic on our switch/router out to the Internet.  This high traffic consists of numerous tcp reset packets between the content security filter/firewall and the default router.  After a number of sniffing sessions and troubleshooting I've figured out how to duplicate the problem and have an idea what's triggering the issue but I'm at a loss on how to resolve it.

We have a wireless router that bypasses the firewall and allows visiting vendors to access to the Internet.  Employees, however, sometimes use this when working with vendors.  Anyway, what happens is if you're plugged into the wired network behind the firewall, connect to the wireless network, unplug the wired connection then reconnect the wired connection you sometime get the high TCP reset traffic.  While sniffing I've seen TCP packets tagged as "Continuation Data" with a source IP address of the wireless card, a destination IP of some registered IP on the Internet (usually some akamai deployment server) followed immediately by the TCP resets.  Subsequent packets alternate these source and destination IP addresses and the traffic seems to go between the default router and the internal interface of our content security filter which is in-line with the firewall.  The only way to stop the traffic is to pull the plug or disable the port at the managed switch.

Does the fact that I'm seeing packets tagged with wireless IP addresses on the wired network make sense to anyone?  That definitely seems like the trigger.  I wouldn’t expect to see that traffic on the wire.

Any thoughts?
Who is Participating?
Optimation-KeithAuthor Commented:
Found that our eSafe content security filter handles a "Continuation Data" packet differently than it used to.  I don't have any specific version info or definite dates but at some point around the end of February 2011 this problem started.  Now when a "Continuation data" packet hits the internal ethernet on the filter, eSafe responds with a TCP reset packet.  If the destination address of the original packet is not a typical internal address, the reset hits the default router which in turn sends it back to the firewall because of the external address but it too get intercepted by eSafe and the process repeats forever causing traffic issues.  The workaround for now is to add an exclusion in eSafe's nitro inspection configuration that excludes the IP range of our external wireless network so eSafe passes the traffic to the firewall. The firewall simply and correctly drops the packet due to address spoofing therefore never creating the TCP reset loop.
Windows works like this, when wireless goes down route disappears and TCP stack tries to reset connections, even it is of no use.
It is safe to discard such packets ASAP.
Optimation-KeithAuthor Commented:
I worked with SafeNet to resolve the problem
Optimation-KeithAuthor Commented:
Correction.  We have found that there were no changes to the eSafe software therefore we're concluding that something may have changed at the OS level.  I've been testing with Windows XP and I'm going to pursue this issue with Microsoft.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.