On Friday 21 July 2006 18:38, Walter Haidinger wrote: > On Fri, 21 Jul 2006, Mike Frantzen wrote: > > Reassemble TCP does aggressive TCP PAWs checks on the TCP timestamps. > > It does the usual PAWs check to make sure a timestamp is not older than > > the last echoed value - which is in theory a wrapped sequence number. > > It also does its aggressive check to make sure the timestamp did not > > increase faster than the fastest clock which the RFC allows - an > > attacker can kill a connection by spoofing a higher timestamp. In > > order to prevent blind TCP spoofing PF's scrub will require TCP > > timestamps on all data packets if the first data packet had a > > timestamp. There are some transparent web caches out there that will > > allow the 3whs to complete (exchanging timestamp information) and then > > they will will hijack the TCP connection. Of course the developers of > > the hijacking device took some liberal shortcuts that make them look > > just like a blind hijacker instead of a MITM hijacker. If they hijack > > in the middle of the data stream (like after they see the HTTP request) > > and stop sending TCP Timestamps then PF's reassemble TCP will block > > further packets. > > How does this interfere with the NAT code? > > Reassemble tcp has _only_ problems from a machine behind the OpenBSD > NAT router. On the router itself or if using a proxy running on it, > there is no problem.
Not sure whether this is relevant, but I had a similiar obscure 'bug' - some pages (from what I found most notably anything on *.free.fr) was timing out from behind the router, while the router itself was opening those pages without any issues. That behaviour disappeared when i commented out the first NAT rule I had in pf.conf: no nat on $ext_if from $int_if to $int_if Now everything works smoothly... Changing scrub one way or the other made no difference, most of the time I had in there: scrub in all > So I'd think that it is actually an OpenBSD bug in the NAT and/or > reassemble tcp code. > > How can this be verified? > > Regards, > Walter -- viq
