> > echo 1 > /proc/sys/net/ipv4/tcp_rfc1337
>
> not the right option; this is different, and to avoid an issue with time wait.
>
> the feature i'm thinking of is time-wait negotiation, which can be
> tweaked to always put this state on the peer (or fail if not
> available).
>
> last time i mess
> On 05/11/2012 07:43 PM, coderman wrote:
> > On Thu, May 10, 2012 at 8:52 PM, Marsh Ray wrote:
> >> ...
> >>> How is it possible for a packet not to have an associated uid?
> >> ...
> >> I'm not a netfilter expert, but it looks this is a pure TCP ACK packet.
> >> With
> >> LEN=40 there's no appl
> On Thu, May 10, 2012 at 10:11:06PM -0400, johnmurphy...@safe-mail.net wrote:
> > IN= OUT=eth0 SRC=192.168.178.50 DST=some-target LEN=40 TOS=0x00 PREC=0x00
> > TTL=64 ID=0 DF PROTO=TCP SPT=50447 DPT=443 WINDOW=1002 RES=0x00 ACK URGP=0
> >
> > This packet is https, most likely generated by my fir
Hi List,
I am trying to tweak my transparent netfilter setup (Tor Stable, Debian Wheezy,
GNU/Linux, iptables v1.4.12.2, Kernel 3.2.0-amd64). So far, redirection and
torification works fine. I have have several users, some of them have their TCP
traffic forwarded to Tor, some are allowed to send
