I have several packet traces from several customers that see this alert. There appears to be a bug in the microsoft TCP stack when connections go stale. What happens is that the last successful segment's last byte is resent with a value of 0xff. This is after the other endhost has ACK'ed the sequence from the last segments.
So for example.
a->b seq=100 data="ABCDEFG"
b->a ack=107 no data
a->b seq=106 data="(0xff)"
The last packet in the example is overwriting the G in the first packet with an 0xff. This causes the IDS to fire. We are working on detecting this stack bug in a new version.
After further investigation I have found that there is an older implementation of TCP keepalives dating back to BSD 4.2 days where the keepalive does hold garbage data. Microsoft's stack was based on some of this older BSD code and therefore shows this behavior. So we have concluded that there is no stack bug in Microsoft's TCP stack. They are just doing something that most stacks do not.
We now know the problem and I will be committing a fix for v4.1.4 of the IDS. It will safely ignore an overwrite if it is a single byte one byte back in the sequence and both ends of the TCP connection have already ack'ed the byte.
Sorry for the delay in solving this problem for you all. If you have lowered the sev or filtered 1300 I would recommend setting your filters and severity back to default after upgrading to v4.1.4.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...