[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] tor/netfilter: packets without uid
On 05/10/2012 09:11 PM, johnmurphy323@xxxxxxxxxxxxx wrote:
I am trying to tweak my transparent netfilter setup (Tor Stable,
Debian Wheezy, GNU/Linux, iptables v18.104.22.168, 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 packets directly. It works splendid.
There is just one issue. About every once or twice a second there is
a tcp packet running along my filter (that is the iptables -t filter)
table that has no associated UID.
This is what they look like:
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 firefox user when I
was browsing a website. But it gets more interesting. There are lost
packets, even when I only use Tor. A reverse dns lookup of the target
ip shows that these are packets send by tor to the first relay.
How is it possible for a packet not to have an associated uid?
Dropping these packets of course works, but the logging clutters my
syslog, and after all, why is there this type of leaking in the first
I'm not a netfilter expert, but it looks this is a pure TCP ACK packet.
With LEN=40 there's no application data in it. It may have been
auto-generated by the kernel as a reply to the external packet and never
tagged with a user for that reason.
Dropping them may result in retransmission. As you noticed, once or
twice a second until there's some user tagged data going out that can
transmit the ack.
Just a theory.
tor-talk mailing list