Your message dated Sun, 10 Jul 2016 16:44:41 +0200 with message-id <[email protected]> and subject line guarddog was removed from Debian in 2011 has caused the Debian Bug report #345759, regarding guarddog: Guarddog fails to allow bidirectional UDP traffic for User Defined Protocols to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 345759: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345759 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: guarddog Version: 2.4.0-1 Severity: important Hi there. Guraddog doesn't writes the second bidirectional iptables command for User Defined UDP protocols. The resutling script has: # Traffic from 'Internet' to 'Local' # Allow 'userdefined3' iptables -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT Instead of: # Traffic from 'Internet' to 'Local' # Allow 'userdefined3' iptables -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT iptables -A f1to0 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT The full history: After setting up Guarddog, my TeamSpeak server stoped working. I had enabled it in Guarddog User Defined Protocols of course. Looking at /var/log/messages, I found: Dec 3 02:06:01 severo kernel: DROPPED IN= OUT=eth1 SRC=10.10.10.1 DST=10.10.10.10 LEN=464 TOS=0x00 PREC=0x00 TTL=64 ID=2 DF PROTO=UDP SPT=8767 DPT=2636 LEN=444 10.10.10.1 is my server, 10.10.10.10 is my client, so it seemed the server was receiving the client request, but the answer packets were being dropped. I then went on checking what was Guarddog's script actually doing with the Teamspeak port (8767): # perl -nwe 'if(/^# Traffic/){$section=$_;$s=0;} # elsif(/^#/){$title=$_;$t=0;} elsif(/8767/i){print( ($s++? "":$section) # . ($t++? "": $title) . $_);}' rc.firewall.test # Traffic from 'Internet' to 'Local' # Allow 'userdefined3' ipchains -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT ipchains -A f1to0 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT # Traffic from 'Local' to 'Internet' # Allow 'userdefined3' ipchains -A f1to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT ipchains -A f0to1 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT # Traffic from 'Red Local' to 'Internet' # Allow 'userdefined3' ipchains -A f2to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT ipchains -A f0to2 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT # Traffic from 'Red Local' to 'Local' # Allow 'userdefined3' ipchains -A f2to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT ipchains -A f1to2 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT # Traffic from 'Internet' to 'Local' # Allow 'userdefined3' iptables -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT # Traffic from 'Local' to 'Internet' # Allow 'userdefined3' iptables -A f1to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT # Traffic from 'Red Local' to 'Internet' # Allow 'userdefined3' iptables -A f2to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT # Traffic from 'Red Local' to 'Local' # Allow 'userdefined3' iptables -A f2to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT At this point it was clear to me that Guarddog was not writing the bidirectional iptables commands for User Defined UDP Protocols (ipchains commands look fine though). After manually adding those: # Traffic from 'Internet' to 'Local' # Allow 'userdefined3' iptables -A f0to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT iptables -A f1to0 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT # Traffic from 'Local' to 'Internet' # Allow 'userdefined3' iptables -A f1to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT iptables -A f0to1 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT # Traffic from 'Red Local' to 'Internet' # Allow 'userdefined3' iptables -A f2to0 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT iptables -A f0to2 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT # Traffic from 'Red Local' to 'Local' # Allow 'userdefined3' iptables -A f2to1 -p udp --sport 0:65535 --dport 8767:8767 -j ACCEPT iptables -A f1to2 -p udp --sport 8767:8767 --dport 0:65535 -j ACCEPT and then restarting Teamspeak, my server was functional again (seems TSS is a bit "sensible" to not being able to answer back, and will not accept new connections after an "EIdSocketError.Host not found." error). Ciao. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages guarddog depends on: ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr ii kdelibs4 4:3.3.2-6.2 KDE core libraries ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libc6 2.3.5-6 GNU C Library: Shared libraries an ii libfam0c102 2.7.0-6 client library to control the FAM ii libgcc1 1:3.4.3-13 GCC support library ii libice6 4.3.0.dfsg.1-14sarge1 Inter-Client Exchange library ii libidn11 0.5.13-1.0 GNU libidn library, implementation ii libpng12-0 1.2.8rel-1 PNG library - runtime ii libqt3c102-mt 3:3.3.4-3 Qt GUI Library (Threaded runtime v ii libsm6 4.3.0.dfsg.1-14sarge1 X Window System Session Management ii libstdc++5 1:3.3.6-10 The GNU Standard C++ Library v3 ii libx11-6 4.3.0.dfsg.1-14sarge1 X Window System protocol client li ii libxext6 4.3.0.dfsg.1-14sarge1 X Window System miscellaneous exte ii libxrender1 0.8.3-7 X Rendering Extension client libra ii xlibs 4.3.0.dfsg.1-14sarge1 X Keyboard Extension (XKB) configu ii zlib1g 1:1.2.2-4.sarge.2 compression library - runtime -- no debconf information
--- End Message ---
--- Begin Message ---Version: 2.6.0-3+rm guarddog was last released with Debian 6.0 (squeeze) in February 2011 and removed from Debian sid/unstable later in 2011 (see http://bugs.debian.org/619736 for details on the removal). Since support for squeeze and squeeze-LTS has now ended, I'm closing all the remaining bugs reported against this package. Andreas
--- End Message ---
