[7.250] IM/P2P buggy

Hi, and thanks for your report!

Do I understand this correctly in that we still have several Winny-related false positives, or are other protocols involved? If yes, please let me know what other culprits there are.

Further assistance from you would also be highly appreciated, as these kind of issues are nearly impossible to fix without packet captures. If at all possible, the following would be most helpful (requires a root shell on the ASG):

0. Configure the ASG like for your report, with all IM/P2P set to "block", etc.

1. "Tag" the afc.log file in some way, to mark the start of a test run. The easiest thing is probably one of the following, as this will either write something to it or completely clear it:

# /var/mdw/scripts/afc restart

or

# > /var/log/afc.log

2. Start two tcpdump(8) instances to capture the traffic, one listening to the "internal" and one to the "external" interface. Have them write to files with somewhat meaningful names. Here is an example (might require additional adjustments with regard to interfaces):

# tcpdump -s0 -w ftp_xpsp3_jana_internal.pcap -i eth0

# tcpdump -s0 -w ftp_xpsp3_jana_external.pcap -i eth1

3. Reproduce the issue -- afc.log should have one or more entries indicating that something was blocked without proper cause. As soon as this happens, the test is done.

4. Rinse and repeat: Copy the PCAPs and afc.log to a safe place and repeat steps 1) to 3) with the other client/server combinations.

... and then attach those PCAPs and afc.log files here, or mail them to mgrimm at astaro dot com. [;)]

I understand that this is an annoying amount of work, but it's also a great chance to get it fixed ASAP.


Thanks a lot, and kind regards,

Moritz

Hi, and thanks for your report!

Do I understand this correctly in that we still have several Winny-related false positives, or are other protocols involved? If yes, please let me know what other culprits there are.

Further assistance from you would also be highly appreciated, as these kind of issues are nearly impossible to fix without packet captures. If at all possible, the following would be most helpful (requires a root shell on the ASG):

0. Configure the ASG like for your report, with all IM/P2P set to "block", etc.

1. "Tag" the afc.log file in some way, to mark the start of a test run. The easiest thing is probably one of the following, as this will either write something to it or completely clear it:

# /var/mdw/scripts/afc restart

or

# > /var/log/afc.log

2. Start two tcpdump(8) instances to capture the traffic, one listening to the "internal" and one to the "external" interface. Have them write to files with somewhat meaningful names. Here is an example (might require additional adjustments with regard to interfaces):

# tcpdump -s0 -w ftp_xpsp3_jana_internal.pcap -i eth0

# tcpdump -s0 -w ftp_xpsp3_jana_external.pcap -i eth1

3. Reproduce the issue -- afc.log should have one or more entries indicating that something was blocked without proper cause. As soon as this happens, the test is done.

4. Rinse and repeat: Copy the PCAPs and afc.log to a safe place and repeat steps 1) to 3) with the other client/server combinations.

... and then attach those PCAPs and afc.log files here, or mail them to mgrimm at astaro dot com. [;)]

I understand that this is an annoying amount of work, but it's also a great chance to get it fixed ASAP.


Thanks a lot, and kind regards,

Moritz

tommorow i have more time for testing [:)]

ASG120 7.201
Commandline ftp from Win2003 x64 (latest updates)
Everything in IM/P2P set to Block
Ftp proxy is disabled, PF have extra rule for ftp-traffic
I try to download u2d-sys-7.201.tgz.gpg from ftp.astaro.com

ftp connect work
ls work
get command stuck
the IM/P2P Classifier logs only 1 entry:

008:07:22-21:14:02 (none) ulogd[2638]: id="2019" severity="info" sys="SecureNet" sub="packetfilter" name="AFC Block" action="drop" fwrule="60214" outitf="eth0" srcip="128.242.114.245" dstip="10.133.168.141" proto="6" length="1492" tos="0x00" prec="0x00" ttl="55" srcport="20" dstport="1104" tcpflags="ACK"

tcpdump files send to mgrimm

regards

Gregor Kemter