On 5/23/06, Andreas Goertz <agoertz at gmx dot com> wrote:
> Hi ..
>
> I got a strange Problem here. I'm testing Monowall for use in our
> production enviroment. And everything works great but this:
>
> Some of our users who are working with a windows client are stressed by
> strange timeouts when they want to access our webservers.

My first guess is something MTU related.  Try dropping the MTU on the
Windows hosts to 1400 and see if that changes anything.


> The funny thing is that our Linux users never ever had this problems. A
> look in the logs shows that they working in a port range from 45000 -
> 52000 ... our windows users working in an 1500 - 2500 range .. dont know
> if this have anything to do with this story but it's interesting to see.
>

Just differences in how the OS's handle and use ephemeral ports.
That's what they were using at that time, if you check back later
they'll likely be using something completely different.

On a somewhat related note (well, not so much, but this reminded me of
this), modern Windows actually handles this type of stuff better (more
securely) than Linux does, the ISN's specifically.  Whoever
implemented ISN randomization in Linux really screwed it up, and Linux
still has easily predictable ISN's.  This means it should be
relatively easy to blind spoof TCP connections to Linux hosts.  see
http://www.bsdcan.org/2006/papers/ImprovingTCPIP.pdf
Linux was the only thing tested that didn't get it right.  All the
BSD's, Cisco IOS, and Windows XP SP2 all do it properly (though there
are differences in implementations).

back on track..


>
> What's this? Why does this rule come in action? I really got no idea ..
>

If a packet isn't initiating a connection, and isn't part of a current
state in the state table, antispoofing rules in the m0n0wall back end
drop that packet.  What I'm guessing you're seeing is a black hole
somewhere, related to MTU, and your retransmits are getting dropped
for that reason (though it wouldn't matter even if they were passed,
as they would likely hit that same black hole).

-Chris