This isn't an actual answer to your question--but I think your problem *may* be a userland/kernel/version/compile problem (which I have no business answering) vs. a configuration syntax problem. What I can tell you--I hopped on a test machine (a suse 9.0 machine): # uname -a Linux test-fw 2.4.21-199-default #1 Fri Mar 12 08:27:41 UTC 2004 i686 i686 i386 GNU/Linux # iptables -V iptables v1.2.8 # iptables -I FORWARD -m string --string testing -j LOG --log-prefix "FW STRING: " I then hit http://my.site.behind.this.firewall/testing/ from an external machine... And these showed up in the logs: Jul 21 03:01:23 test-fw kernel: FW STRING: IN=eth1 OUT=eth0 SRC=clientip DST=serverip LEN=543 TOS=0x00 PREC=0x00 TTL=39 ID=39276 DF PROTO=TCP SPT=40746 DPT=80 WINDOW=5840 RES=0x00 ACK PSH URGP=0 Jul 21 03:01:23 test-fw kernel: FW STRING: IN=eth0 OUT=eth1 SRC=serverip DST=clientip LEN=889 TOS=0x00 PREC=0x00 TTL=63 ID=32019 DF PROTO=TCP SPT=80 DPT=40746 WINDOW=6432 RES=0x00 ACK PSH URGP=0 So, the theory works--it matched in both a request and a reply. And the rule syntax you posted appears to be valid... Like I said--not an answer, but maybe someone else on the list can shed some light on your specific kernel/iptables/pom version and maybe a possible issue with string matching? -j -----Original Message----- From: gypsy [mailto:gypsy@xxxxxxxxxx] Sent: Wednesday, July 21, 2004 2:08 AM To: Jason Opperisano; netfilter Subject: Re: Asking again: string match fails to find anything Jason Opperisano wrote: > > is it possible that a rule above your "-m string --string $STRING" is matching the data packets of the connection; i.e, a "-m state --state ESTABLISHED -j ACCEPT" rule? > > -j | No. That V "I" down there says not. > iptables -I INPUT -m string --string $STRING -j LOG ^ | Gypsy
