Hey all, I wonder if anyone can help explain something, it might be a problem on my firewall, my local machine configuration or with the ktorrent client, I cannot tell which, in essence when using ktorrent my firewall is logging tens of thousands of packets like this

Code: Select all

16:34:01 kernel IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=46017 DF PROTO=TCP SPT=37866 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0
16:34:07 kernel IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=46019 DF PROTO=TCP SPT=37866 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0
16:34:18 kernel IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6621 DF PROTO=TCP SPT=37955 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0
16:34:21 kernel IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6623 DF PROTO=TCP SPT=37955 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0
16:34:27 kernel IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6625 DF PROTO=TCP SPT=37955 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0



I am behind a nat, iptables firewall, 192.168.1.5 is my lan box running ktorrent, the firewall is at 192.168.1.1, my port usage in ktorrent is 13762
both tcp and udp are forwarded on the firewall box thus

Code: Select all

/sbin/iptables -A portfwf -m state --state NEW -i eth2 -p tcp -s 0.0.0.0/0 -d 192.168.1.5 --dport 13762 -j ACCEPT
/sbin/iptables -t nat -A portfw -p tcp -s 0.0.0.0/0 -d 82.xxx.xxx.xxx --dport 13762 -j DNAT --to 192.168.1.5:13762


and the same for udp thus

Code: Select all

/sbin/iptables -A portfwf -m state --state NEW -i eth2 -p udp -s 0.0.0.0/0 -d 192.168.1.5 --dport 13762 -j ACCEPT
/sbin/iptables -t nat -A portfw -p udp -s 0.0.0.0/0 -d 82.xxx.xxx.xxx --dport 13762 -j DNAT --to 192.168.1.5:13762


giving

Code: Select all

Chain portfwf (1 references)
 pkts bytes target     prot opt in     out     source               destination
   20  1028 ACCEPT     tcp  --  eth2   *       0.0.0.0/0            192.168.1.5        state NEW tcp dpt:13762
  248 32842 ACCEPT     udp  --  eth2   *       0.0.0.0/0            192.168.1.5        state NEW udp dpt:13762


and

Code: Select all

Chain portfw (1 references)
 pkts bytes target     prot opt in     out     source               destination
  116  6716 DNAT       tcp  --  *      *       0.0.0.0/0            82.xxx.xxx.xxx      tcp dpt:13762 to:192.168.1.5:13762
  267 35241 DNAT       udp  --  *      *       0.0.0.0/0            82.xxx.xxx.xxx       udp dpt:13762 to:192.168.1.5:13762


this is all going to wrap horribly I just know it will be an illegible scrunch of numbers, but ...

The firewall is a smoothwall box kernel 2.4.32 which has served admirably for years and is performing perfectly as ever, eth0 is the internal lan, eth1 is mostly unused but is a spare lan, a dmz and eth2 is the external facing interface with the public ip.

On the internal host running (FC3 2.6.12-2.3.legacy_FC3) ktorrent, the firewall is also active but the appropriate ports are open

Code: Select all

/sbin/iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 13762 -j ACCEPT
/sbin/iptables -A INPUT -p udp -m state --state NEW -m udp --dport 13762 -j ACCEPT


Code: Select all

 9085  447K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:13762
12474 1785K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW udp dpt:13762


ok everything is fine uploading and downloading are great, DHT looks like it's working too, it has nodes and occasionally tasks

So what the hell am I **** about?

My firewall logs are bursting with these inexplicable packets as at the top of the message

Code: Select all

16:34:27 kernel IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6625 DF PROTO=TCP SPT=37955 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0

the source port (SPT) is a random high port, the source SRC ip is 192.168.1.5 and the DST is also 192.168.1.5 and the DPT is 13762, the port ktorrent is listening on and accepting connections on

why are these even going out on the wire and hitting the firewalls internal interface, why is ktorrent trying every 6 seconds to connect (SYN) to itself using the lan ip of itself and why are these hitting the wire instead of just being handled by the kernel internally.

I'm pretty knowledgable but this is driving me round the twist and my firewall logs and filled with this junk, why is the router even seeing these at all as being contained on the local lan it should just blank them.


Had this on 2.0.2 same on 2.0.3.

p.s. I'm not really pulling my hair out but if I understood better what is going on or even found away to stop this behaviour I would be happier.

tommy wrote:My firewall logs are bursting with these inexplicable packets as at the top of the message

Code: Select all

16:34:27 kernel IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=6625 DF PROTO=TCP SPT=37955 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0

the source port (SPT) is a random high port, the source SRC ip is 192.168.1.5 and the DST is also 192.168.1.5 and the DPT is 13762, the port ktorrent is listening on and accepting connections on

why are these even going out on the wire and hitting the firewalls internal interface, why is ktorrent trying every 6 seconds to connect (SYN) to itself using the lan ip of itself and why are these hitting the wire instead of just being handled by the kernel internally.

That is also strange, if ktorrent were to connect to itself, you would expect the WAN IP address as the destination address. Maybe NAT is allready applied when the packets are logged, and the actual destination address is the WAN IP address ?

You should try running ethereal on your LAN computer and then try to match the port number with your firewall logs for TCP SYN packets.

George wrote:

You should try running ethereal on your LAN computer and then try to match the port number with your firewall logs for TCP SYN packets.

It seems to make three attempts with each random high source port, this snip is from the firewall log on the router box

Code: Select all

Oct 12 18:26:47 firewall kernel: IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=23256 DF PROTO=TCP SPT=48513 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0

Code: Select all

Oct 12 18:26:50 firewall kernel: IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=23258 DF PROTO=TCP SPT=48513 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0

Code: Select all

Oct 12 18:26:56 firewall kernel: IN=eth0 OUT=eth0 SRC=192.168.1.5 DST=192.168.1.5 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=23260 DF PROTO=TCP SPT=48513 DPT=13762 WINDOW=5840 RES=0x00 SYN URGP=0

showing three tries with SPT=SPT=48513, then it repeats again with different SPT, next is 3x 48534, next again is 48547, no pattern there.

Below is the same 3 SYN packets as they left the nat'd box (192.168.1.5)
as you can see their destination 82.xxx.xxx.xxx is my routers external IP, I've munged it but any bright spark can figure it out if from the hex.

1 hourtime difference is due to GMT/BST

Code: Select all

2006-10-12 17:26:44.953296 00:0a:48:0f:80:15 > 00:20:af:35:df:d2, ethertype IPv4 (0x0800), length 74: IP (tos 0x0, ttl  64, id 23256, offset 0, flags [DF], proto 6, length: 60) 192.168.1.5.48513 > 82.xxx.xxx.xxx.13762: S [tcp sum ok] 3764698419:3764698419(0) win 5840 <mss 1460,sackOK,timestamp 107276267 0,nop,wscale 2>
        0x0000:  0020 af35 dfd2 000a 480f 8015 0800 4500  ...5....H.....E.
        0x0010:  003c 5ad8 4000 4006 3116 c0a8 0105 521a  .<Z.@.@.1.....R.
        0x0020:  9b06 bd81 35c2 e064 bd33 0000 0000 a002  ....5..d.3......
        0x0030:  16d0 033b 0000 0204 05b4 0402 080a 0664  ...;...........d
        0x0040:  e7eb 0000 0000 0103 0302                 ..........


Code: Select all

2006-10-12 17:26:47.952336 00:0a:48:0f:80:15 > 00:20:af:35:df:d2, ethertype IPv4 (0x0800), length 74: IP (tos 0x0, ttl  64, id 23258, offset 0, flags [DF], proto 6, length: 60) 192.168.1.5.48513 > 82.xxx.xxx.xxx.13762: S [tcp sum ok] 3764698419:3764698419(0) win 5840 <mss 1460,sackOK,timestamp 107279267 0,nop,wscale 2>
        0x0000:  0020 af35 dfd2 000a 480f 8015 0800 4500  ...5....H.....E.
        0x0010:  003c 5ada 4000 4006 3114 c0a8 0105 521a  .<Z.@.@.1.....R.
        0x0020:  9b06 bd81 35c2 e064 bd33 0000 0000 a002  ....5..d.3......
        0x0030:  16d0 f782 0000 0204 05b4 0402 080a 0664  ...............d
        0x0040:  f3a3 0000 0000 0103 0302                 ..........



Code: Select all

2006-10-12 17:26:53.951424 00:0a:48:0f:80:15 > 00:20:af:35:df:d2, ethertype IPv4 (0x0800), length 74: IP (tos 0x0, ttl  64, id 23260, offset 0, flags [DF], proto 6, length: 60) 192.168.1.5.48513 > 82.xxx.xxx.xxx.13762: S [tcp sum ok] 3764698419:3764698419(0) win 5840 <mss 1460,sackOK,timestamp 107285267 0,nop,wscale 2>
        0x0000:  0020 af35 dfd2 000a 480f 8015 0800 4500  ...5....H.....E.
        0x0010:  003c 5adc 4000 4006 3112 c0a8 0105 521a  .<Z.@.@.1.....R.
        0x0020:  9b06 bd81 35c2 e064 bd33 0000 0000 a002  ....5..d.3......
        0x0030:  16d0 e012 0000 0204 05b4 0402 080a 0665  ...............e
        0x0040:  0b13 0000 0000 0103 0302                 ..........



As you can see it is connecting to itself but rather than using 127.0.0.1 or 192.168.1.5, it is using the real external interface of the router as the destination which is not going to work in a NAT setup.

Thanks for your help in running this down, I'm not sure if this is something that can be fixed but if it can determine that the external ip is not on any local interface, and act accordingly, it sure would keep my logs quieter. I've no knowledge what it is trying to do when connecting to itself in these instances and whether any functionality is lost by its inability to do so.

Just a wild shot in the dark, when DHT gets a list of PotentialPeers, itself is always in the list. Could it be ktorrent trying to connect to itself from what DHT is telling it, and NAT is translating that attempt back into the private IP via his port forwarding rules?

jdong wrote:

Just a wild shot in the dark, when DHT gets a list of PotentialPeers, itself is always in the list. Could it be ktorrent trying to connect to itself from what DHT is telling it, and NAT is translating that attempt back into the private IP via his port forwarding rules?

Yeah I think that's it on both count jdongs, turning off DHT did not stop it immediately, possibly an afterglow efect, but stopping uploads then exiting the client has ended that logging. I was looking at it from the point of view that it wanted to connect to itself but now realise that my own ip was just one of many and indistinguishable. And NAT was just just doing its job. There is an element of chicken and egg about it then, if it does not know what its eventual routable ip is to the outside world it cannot exclude itself unless the user supplies it with it's own external ip not in the style of say passive ftp where it is used by supplying it to the connecting client on the control port but in order to exclude it from using it itself, although if it could just somehow query a remote DTH client to say 'who the hell am I?'

Anyhow I just installed this recently the other day just to grab one file I was interested in, it looks a nice stable and very friendly client, last time I tried some java based thing and couldn't get rid of it quickly enough it was so bad.

Understanding the problem is more than half way to solving it.

thx guys/gals

In order to register with DHT, I would imagine that the client should be able to figure out its own actual public IP....

jdong wrote:In order to register with DHT, I would imagine that the client should be able to figure out its own actual public IP....

Not really, the other peers will learn your IP address, from where your announce message came from and will add it to their internal database and pass it along to other peers.

And when you ask one of those other peers for a list of peers, yours can be in there.

We don't really check on this, because we will automatically refuse connections from ourself.

Ah, ok. Well, personally I also think this kind of behavior is harmless other than making the administrator filter out the entries from firewall logs.