Constant problems with PeerG with Clarkconnect

		Phoenix Labs > Projects > PeerGuardian Linux
Constant problems with PeerG with Clarkconnect

FAQ

Page 1 of 2

Thread Tools

Display Modes


08-28-2005, 05:02 AM	#1
Country: Posts: n/a	Constant problems with PeerG with Clarkconnect Note from JFM: This thread has been made sticky because it is a common problem that has been solved. Read this thread for the reasons behind the problem and the solution. Hi, I've been wanting to move the PG stuff from this Win32 box to the gateway (running clarkconnect v3). Anyway through reading lots of pages to taking a look at the prebuit tar files i've managed to get PG linux compiled and start. However, It doesnt appear to block everything as I can see in my protowall logs on windows traffic inbound that SHOULD have been blocked by the linux box. Both machines use the same blocklist and when PG starts on Linux the number of ips blocked and the number of ranges blocked match the win32 box exactly. When I start pgtext and search for an ip it crashes the peerguardnf process This is the contents of my log Code: [root@server log]# tail -f PG.log Entering daemon mode Allowing all traffic on port 80 Blocking 65371 ranges (871082849 IP addresses) error: $ Reading blocklist detected ASCII blocklist Entering daemon mode Allowing all traffic on port 80 Blocking 65371 ranges (871082849 IP addresses) error: $ You can see it crashed (and i restarted it). When i dont search for the ip and check with pgtext what is going on, i see it says a figure in "inspected packets" so it is checking packets. Any ideas?. Its running on a P4 1.8Ghz that does nothing else but be a gateway, 768megs ram. only max 5 users on the gateway (very low load).


08-28-2005, 05:14 AM	#2
Country: Posts: n/a	Here is a screen grab from pgtext


08-28-2005, 06:05 AM	#3
Country: Posts: n/a	Hrm...some connections are leaking through Here is logs from windows box running protowall. Code: ProtoWall v2.00(build 2007) [Beta] LOGGING STARTED on Sunday, August 28, 2005 at 12:00:46 -------------------------------------------------------------------------------- There are 871082849 known IP addresses in 65371 ranges. 2005/08/28 12:03:30 [->] REJECTED - Source is Ministry of Education Computer Center (140.115.152.139) [Protocol: TCP - src: 2462 / dst: 5662] 2005/08/28 12:03:33 [->] REJECTED - Source is Ministry of Education Computer Center (140.115.152.139) [Protocol: TCP - src: 2462 / dst: 5662] 2005/08/28 12:03:39 [->] REJECTED - Source is Ministry of Education Computer Center (140.115.152.139) [Protocol: TCP - src: 2462 / dst: 5662] in pgtext the number of blocked packets is 1 (so it is sorta working). I see the following Code: ... Blocking 65371 ranges (871082849 IP addresses) dropped src: 204.44.110.174 dst: 82.47.XXX.XX (Phelps Dodge Corporation) btw I've X'd my octals. Anyway, there is an entry in my block list, you can see there IS an entry for the 140.155 range, its just not being blocked Code: [root@server etc]# grep 140.115 antip2p.pg Rahmel Verlag GmbH:62.8.140.112-62.8.140.115 Ministry of Education Computer Center:140.115.0.0-140.115.255.255 [root@server etc]#

08-28-2005, 06:56 AM

JFM

Public Relations

Join Date: Sep 2005

Location: Kent, UK

Country:

Posts: 2,501

hmm interesting....

this could be a problem with your FORWARD rules in iptables, we've had this problem before with gateways. your FORWARD rules needs the first rule to be QUEUE, which is where pg gets it's traffic from.

this is from iptables --list

Quote:

Chain OUTPUT (policy DROP)
target prot opt source destination
QUEUE all -- anywhere anywhere

but look at FORWARD:

Quote:

Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5
LOG_FILTER all -- anywhere anywhere
LOG all -- anywhere anywhere LOG level info prefix `Unknown Forward'

here there is not always a FORWARD rule. I suggest you use a nice iptables GUI or some manual commandline work and add in a queue rule to all from anywhere to the FORWARD chain

__________________
Joseph Farthing
Public Relations


08-28-2005, 08:12 AM	#5
Country: Posts: n/a	thanks for the quick reply.. The problem here of course is the rules are rebuilt everytime you play with the existing gui tool to port fwd or anyting. here is what the -- list shows for me Code: Chain INPUT (policy DROP) target prot opt source destination ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT icmp -- anywhere anywhere icmp time-exceeded ACCEPT icmp -- anywhere anywhere icmp echo-request DROP icmp -- anywhere anywhere DROP all -- anywhere anywhere state INVALID REJECT tcp -- anywhere anywhere tcp flags:SYN,ACK/SYN,ACK state NEW reject-with tcp-reset DROP tcp -- anywhere anywhere tcp flags:!SYN,RST,ACK/SYN state NEW ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere drop-reserved all -- loopback/8 anywhere drop-reserved all -- 2.0.0.0/8 anywhere drop-reserved all -- 96.0.0.0/3 anywhere drop-reserved all -- 169.254.0.0/16 anywhere drop-reserved all -- 223.0.0.0/8 anywhere drop-reserved all -- BASE-ADDRESS.MCAST.NET/4 anywhere drop-reserved all -- 240.0.0.0/4 anywhere ACCEPT udp -- anywhere somehost.somenetwork.com udp spt:bootps dpt:bootpc ACCEPT tcp -- anywhere somehost.somenetwork.com tcp spt:bootps dpt:bootpc ACCEPT tcp -- anywhere somehost.somenetwork.com tcp dpt:1875 ACCEPT udp -- anywhere somehost.somenetwork.com udp dpts:1024:65535 state RELATED,ESTABLISHED ACCEPT tcp -- anywhere somehost.somenetwork.com tcp dpts:1024:65535 state RELATED,ESTABLISHED DROP all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination ACCEPT tcp -- anywhere p313 tcp dpt:9881 ACCEPT udp -- anywhere p313 udp dpt:9881 ACCEPT tcp -- anywhere p313 tcp dpt:5662 ACCEPT udp -- anywhere p313 udp dpt:5672 ACCEPT tcp -- anywhere p313 tcp dpt:auth ACCEPT tcp -- anywhere p313 tcp dpts:2048:nfs DROP all -- 192.168.0.0/24 p1w18.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w19.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w20.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w1.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w2.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w3.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w3.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w16.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w6.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w17.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w8.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w5.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w2.geo.scd.yahoo.com DROP all -- 192.168.0.0/24 p1w20.geo.scd.yahoo.com DROP tcp -- 192.168.0.0/24 anywhere tcp dpt:http ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED DROP all -- anywhere anywhere Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- somehost.somenetwork.com anywhere tcp spt:bootpc dpt:bootps ACCEPT udp -- somehost.somenetwork.com anywhere udp spt:bootpc dpt:bootps ACCEPT tcp -- somehost.somenetwork.com anywhere tcp spt:1875 ACCEPT all -- somehost.somenetwork.com anywhere DROP all -- anywhere anywhere Chain drop-lan (0 references) target prot opt source destination DROP all -- anywhere anywhere Chain drop-reserved (7 references) target prot opt source destination DROP all -- anywhere anywhere


08-28-2005, 08:12 AM	#6
Country: Posts: n/a	where "somehost.somenetwork.com" is my actual hostname on the inet. removed so i dont get spammed etc.

08-28-2005, 08:27 AM

JFM

Public Relations

Join Date: Sep 2005

Location: Kent, UK

Country:

Posts: 2,501

hmm no queues anywhere...

if you open a terminal on the linux box can you ping ips in the blocklist?

i'm wondering if without QUEUE it might be totally ineffective (because no traffic is being sent to PG)- i could be wrong, i'm thinking in terms of a problem that might be specific to a specific situation

try...

iptables -I FORWARD 1 -j QUEUE

see if that works, it worked here

see the new --list

Quote:

Chain FORWARD (policy DROP)
target prot opt source destination
QUEUE all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere limit: avg 10/sec burst 5
LOG_FILTER all -- anywhere anywhere
LOG all -- anywhere anywhere LOG level info prefix `Unknown Forward'

if that works then add the same rule to OUTPUT and INPUT as well

__________________
Joseph Farthing
Public Relations

08-28-2005, 08:35 AM

Country:

Posts: n/a

Quote:

Originally Posted by JFM

hmm no queues anywhere...

if you open a terminal on the linux box can you ping ips in the blocklist?

Nope!..

here is what I see in pgtext with the one that gets through to the Win32 box (when i try and ping it on the gateway)

Code:

dropped src: 82.47.XXX.XXX dst: 140.115.152.139 (Ministry of Education)..

Just had a thought.. Could it be because I port forward the ports that peerguardian is not seeing the traffic?. Obviously as ICMP is not on the same port as my forward rule for p2p it gets handled by the "normal" rules and thus filtered by peerguard ?


08-28-2005, 08:41 AM	#9
Country: Posts: n/a	jus tried to ping that ip from the win32 box, works fine Code: C:\Documents and Settings\Administrator>ping 140.115.152.139 Pinging 140.115.152.139 with 32 bytes of data: Reply from 140.115.152.139: bytes=32 time=412ms TTL=114 Reply from 140.115.152.139: bytes=32 time=394ms TTL=114 Reply from 140.115.152.139: bytes=32 time=422ms TTL=114 Reply from 140.115.152.139: bytes=32 time=416ms TTL=114 Ping statistics for 140.115.152.139: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 394ms, Maximum = 422ms, Average = 411ms C:\Documents and Settings\Administrator> And now the same test on the gateway Code: [root@server root]# ping 140.115.152.139 PING 140.115.152.139 (140.115.152.139) 56(84) bytes of data. --- 140.115.152.139 ping statistics --- 7 packets transmitted, 0 received, 100% packet loss, time 5998ms [root@server root]# So it would seem the filter works great on the linux box, but not doing its thing for the internal lan. Btw the gateway has two nics, one for the inet connection and one for the internal lan.


08-28-2005, 08:43 AM	#10
*JFM* Public Relations Join Date: Sep 2005 Location: Kent, UK Country: Posts: 2,501	could be possible... the first thing that all connections should see is the QUEUE rule... i think that most distributions use a setup that has a kind of "pre-existing" QUEUE rule for INPUT and OUTPUT. does adding that queue rule help at all? the command i gave forces it to be the FIRST rule that anything sees in FORWARD __________________ Joseph Farthing Public Relations

Page 1 of 2

« Previous Thread | Next Thread »

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Posting Rules
You may not post new threads You may not post replies You may not post attachments You may not edit your posts vB code is On Smilies are On [IMG] code is On HTML code is Off

Forum Jump

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Constant 'Exception Occurred' Errors	Whitey	Technical Support	4	08-15-2009 07:27 AM
Core 2 Users, Heat problems?	kidcash	Hardware Isle	5	10-05-2006 06:22 AM
AVG & Ewido update problems	estradion	Technical Support	3	09-01-2006 02:58 PM
Problems with peerGuardian2	spiffyville	Technical Support	5	02-22-2006 09:33 AM
64 bit problems?	mistshadow2k4	General Discussion	3	02-13-2006 11:37 AM

All times are GMT -5. The time now is 07:26 AM.