http://blog.gmane.org/gmane.comp.security.firewalls.netfilter.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44495 <pre> Well, yes, I've heard of, and have used, iptables-restore. But I don't recall ever seeing mention of such a feature or how it works. Now that I'm aware of it, I's'll have to investigate. Thanks, N -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Neal Murphy 2012-05-23T22:03:18 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44494 <pre> What, never heard of iptables-restore? Atomic replace has been in iptables since a long long time. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Jan Engelhardt 2012-05-23T21:53:39 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44493 <pre>I knew I'd eventually remember why I subscribed to this list.... While working on enhancing my firewall, it occurred to me that it'd be real nice to have a 'swap chain' feature in iptables that is equivalent to the 'swap set' feature in ipset. Such a feature would minimize the amount of time that rules are unavailable when adding, changing or deleting them. At present, all the rules in the chain being modified are deleted, then the new rules are added. So there is a period of time, albeit brief, that rules are not available in that chain. Were there a 'swap chain' command, one could build a new chain of the changed rules, swap the new and old chains, then flush and delete the new (now old) chain. This would all but guarantee that no packets 'slip by' (are overlooked). Thanks, N -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Neal Murphy 2012-05-23T21:25:58 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44492 <pre>Hello, I am trying to limit the total number of concurrent connections that may be established on a given port. I need additional connection attempts to be explicitly rejected, so I went for something like: iptables -P INPUT DROP iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 80 -m connlimit --connlimit-above 512 --connlimit-mask 0 -j REJECT iptables -A INPUT -p tcp --dport 80 -j ACCEPT My problem is, when the limit is reached and new connections are rejected, those stay in the conntrack table in a SYN_SENT / UNREPLIED state, and are only cleaned up after 120 seconds (ip_conntrack_tcp_timeout_syn_sent). As such, they are accounted for as active connections by connlimit, and new connections keep being rejected even though the number of established connections is, in fact, lower than the limit that I set. If connections keep coming in at a fast pace, it may just never accept a connection again. I've tried "--reject-with tcp-reset" and the behavior was the same. Would there be a way to work around it? I was hoping RESET'ed connections would not cause an entry to exist in the conntrack table at all (as if I did a DROP). Otherwise, connlimit would have to know somehow that those are dead connections. Lowering tcp_timeout_syn_sent mitigates the problem, but isn't a definitive solution. Version details (Debian Squeeze): Linux 2.6.32-5-amd64 iptables v1.4.8 Thanks, </pre> Eric Petit 2012-05-23T15:29:46 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44490 <pre>Hi I follow a ping through my gateway with log-commands at the end of each chain: Receiving a echo request on eth1 and forwarding it encrypted to a gateway on eth0 works as expected: (Although nat_OUTPUT is missing between step 9 and 10 and nat_POSTROUTING is missing after step 11 compared to http://inai.de/images/nf-packet-flow.png, but I expect this to be correct, as I do not use nat.) 1. May 19 18:58:11 vpn-a kernel: [ 4396.217687] raw_PREROUTING: IN=eth1 OUT= MAC=00:16:3e:0f:01:01:00:16:3e:0f:03:00:08:00 SRC=10.1.1.2 DST=10.2.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230 SEQ=1 2. May 19 18:58:11 vpn-a kernel: [ 4396.217702] mangle_PREROUTING: IN=eth1 OUT= MAC=00:16:3e:0f:01:01:00:16:3e:0f:03:00:08:00 SRC=10.1.1.2 DST=10.2.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230 SEQ=1 MARK=0x1 3. May 19 18:58:11 vpn-a kernel: [ 4396.217710] nat_PREROUTING: IN=eth1 OUT= MAC=00:16:3e:0f:01:01:00:16:3e:0f:03:00:08:00 SRC=10.1.1.2 DST=10.2.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230 SEQ=1 MARK=0x1 4. May 19 18:58:11 vpn-a kernel: [ 4396.217725] mangle_FORWARD: IN=eth1 OUT=eth0 MAC=00:16:3e:0f:01:01:00:16:3e:0f:03:00:08:00 SRC=10.1.1.2 DST=10.2.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230 SEQ=1 MARK=0x1 5. May 19 18:58:11 vpn-a kernel: [ 4396.217732] filter_FORWARD: IN=eth1 OUT=eth0 MAC=00:16:3e:0f:01:01:00:16:3e:0f:03:00:08:00 SRC=10.1.1.2 DST=10.2.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230 SEQ=1 MARK=0x1 6. May 19 18:58:11 vpn-a kernel: [ 4396.217739] mangle_POSTROUTING: IN= OUT=eth0 SRC=10.1.1.2 DST=10.2.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230 SEQ=1 MARK=0x1 7. May 19 18:58:11 vpn-a kernel: [ 4396.217744] nat_POSTROUTING: IN= OUT=eth0 SRC=10.1.1.2 DST=10.2.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=41230 SEQ=1 MARK=0x1 8. May 19 18:58:11 vpn-a kernel: [ 4396.217769] raw_OUTPUT: IN= OUT=eth0 SRC=10.5.0.1 DST=10.5.0.2 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0xc509ff52 MARK=0x1 9. May 19 18:58:11 vpn-a kernel: [ 4396.217776] mangle_OUTPUT: IN= OUT=eth0 SRC=10.5.0.1 DST=10.5.0.2 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0xc509ff52 MARK=0x1 10. May 19 18:58:11 vpn-a kernel: [ 4396.217781] filter_OUTPUT: IN= OUT=eth0 SRC=10.5.0.1 DST=10.5.0.2 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0xc509ff52 MARK=0x1 11. May 19 18:58:11 vpn-a kernel: [ 4396.217786] mangle_POSTROUTING: IN= OUT=eth0 SRC=10.5.0.1 DST=10.5.0.2 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ESP SPI=0xc509ff52 MARK=0x1 Receiving the encrypted echo reply on eth0 and decrypting it works as well, but it does not get forwarded as expected: (nat_PREROUTING is missing between steps 2 and 3 compared to http://inai.de/images/nf-packet-flow.png, but again, I don't use nat so I think this is correct.) 1. May 19 18:58:11 vpn-a kernel: [ 4396.218074] raw_PREROUTING: IN=eth0 OUT= MAC=00:16:3e:0f:01:00:00:16:3e:0f:02:00:08:00 SRC=10.5.0.2 DST=10.5.0.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=5897 PROTO=ESP SPI=0xc0321da6 2. May 19 18:58:11 vpn-a kernel: [ 4396.218082] mangle_PREROUTING: IN=eth0 OUT= MAC=00:16:3e:0f:01:00:00:16:3e:0f:02:00:08:00 SRC=10.5.0.2 DST=10.5.0.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=5897 PROTO=ESP SPI=0xc0321da6 MARK=0x1 3. May 19 18:58:11 vpn-a kernel: [ 4396.218090] mangle_INPUT: IN=eth0 OUT= MAC=00:16:3e:0f:01:00:00:16:3e:0f:02:00:08:00 SRC=10.5.0.2 DST=10.5.0.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=5897 PROTO=ESP SPI=0xc0321da6 MARK=0x1 4. May 19 18:58:11 vpn-a kernel: [ 4396.218097] filter_INPUT: IN=eth0 OUT= MAC=00:16:3e:0f:01:00:00:16:3e:0f:02:00:08:00 SRC=10.5.0.2 DST=10.5.0.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=5897 PROTO=ESP SPI=0xc0321da6 MARK=0x1 5. May 19 18:58:11 vpn-a kernel: [ 4396.218120] raw_PREROUTING: IN=eth0 OUT= MAC=00:16:3e:0f:01:00:00:16:3e:0f:02:00:08:00 SRC=10.2.1.2 DST=10.1.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=60912 PROTO=ICMP TYPE=0 CODE=0 ID=41230 SEQ=1 6. May 19 18:58:11 vpn-a kernel: [ 4396.218129] mangle_PREROUTING: IN=eth0 OUT= MAC=00:16:3e:0f:01:00:00:16:3e:0f:02:00:08:00 SRC=10.2.1.2 DST=10.1.1.2 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=60912 PROTO=ICMP TYPE=0 CODE=0 ID=41230 SEQ=1 But that's all. It never reaches mangle_FORWARD as expected. My setup is below. I don't understand why that packet does not get routed... Can someone here tell me why? Best regards, Steffen # ip rule list 0: from all lookup local 1: from all fwmark 0x1 lookup 100 220: from all lookup 220 32766: from all lookup main 32767: from all lookup default # ip route list table 100 default via 10.5.0.2 dev eth0 proto static src 10.1.1.1 # ip route list table 220 (empty) 4 # ip route list default via 192.168.178.100 dev eth3 10.1.1.0/24 dev eth1 proto kernel scope link src 10.1.1.1 10.1.2.0/24 dev eth2 proto kernel scope link src 10.1.2.1 10.5.0.0/24 dev eth0 proto kernel scope link src 10.5.0.1 192.168.178.0/24 dev eth3 proto kernel scope link src 192.168.178.1 iptables (all chains ACCEPT) has only these rules (except for logging at the end): -t raw -A PREROUTING -j MARK --set-xmark 0x0/0xffffffff -t mangle -A PREROUTING -s 10.1.1.0/24 -d 10.2.1.0/24 -j MARK --set-xmark 0x1/0xffffffff -t mangle -A PREROUTING -p esp -j MARK --set-xmark 0x1/0xffffffff # ip x s src 10.5.0.1 dst 10.5.0.2 proto esp spi 0xc509ff52 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 1/0xffffffff auth-trunc hmac(sha1) 0xfb8cd76020e5bd6e78134961052af497cfbe819e 96 enc cbc(aes) 0xbd46ce27cadc3f34930c39bd9abd5eb1 src 10.5.0.2 dst 10.5.0.1 proto esp spi 0xc0321da6 reqid 1 mode tunnel replay-window 32 flag af-unspec mark 1/0xffffffff auth-trunc hmac(sha1) 0xebda4251938915491005779d63e31f4d0a42c34a 96 enc cbc(aes) 0x48611761f98b6f260ce6db52923bd183 # ip x p src 10.2.1.0/24 dst 10.1.1.0/24 dir fwd priority 1859 mark 1/0xffffffff tmpl src 10.5.0.2 dst 10.5.0.1 proto esp reqid 1 mode tunnel src 10.2.1.0/24 dst 10.1.1.0/24 dir in priority 1859 mark 1/0xffffffff tmpl src 10.5.0.2 dst 10.5.0.1 proto esp reqid 1 mode tunnel src 10.1.1.0/24 dst 10.2.1.0/24 dir out priority 1859 mark 1/0xffffffff tmpl src 10.5.0.1 dst 10.5.0.2 proto esp reqid 1 mode tunnel src ::/0 dst ::/0 socket in priority 0 src ::/0 dst ::/0 socket out priority 0 src ::/0 dst ::/0 socket in priority 0 src ::/0 dst ::/0 socket out priority 0 src ::/0 dst ::/0 socket in priority 0 src ::/0 dst ::/0 socket out priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 </pre> Steffen Heil (Mailinglisten 2012-05-19T19:12:22 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44489 <pre>Hi First of all, sorry for the previous posts. After taking some time off and giving this a fresh look, I realized I did not only do some copy and paste errors for these mails, but also my focus for the correct matching conditions was that fixed, that I totally overlooked having "-D" instead of "-A" in some of my commands. Obviously they didn't work... My sincere apologies for that. Now, I got the following working: iptables -t mangle -A PREROUTING --proto esp -m esp --espspi 0xc522b7f3 -j MARK --set-mark 1 I tried to transform that to iptables -t mangle -A PREROUTING --proto esp -m policy --spi 0xc522b7f3 -j MARK --dir in --set-mark 1 But then it does not work anymore. Is there any fundamental difference between those conditions that I do not understand? Note: My original target was to use reqid instead of spi, because I can fix the reqid and the filewall rules should be independent of IKE... Regards, Steffen </pre> Steffen Heil (Mailinglisten 2012-05-19T11:33:03 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44488 <pre>hi guys, has anyone ever tried queue/nfqueue target in ebtables? I'm not sure if it has been implemented in ebtables, though it has in iptables. Or does community plan to implement it in the future? thank you very much BRs jerry -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> JieYue Ma 2012-05-18T16:44:07 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44487 <pre> Hi Robe Your problem looks insteresting. I would like how reacreate your problem and test further. Do you have any methods? -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Vairavan 2012-05-18T14:51:14 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44484 <pre>Another fact: I added a logging rule and I got logged: May 18 09:27:00 vpn-a kernel: [49503.963182] mangle_PREROUTING: IN=eth0 OUT= MAC=00:16:3e:0f:01:00:00:16:3e:0f:02:00:08:00 SRC=10.5.0.2 DST=10.5.0.1 LEN=152 TOS=0x00 PREC=0x00 TTL=64 ID=56019 PROTO=ESP SPI=0xc89f8130 My mange / POSTROUTING rules: -s 10.1.1.0/24 -d 10.2.1.0/24 -j MARK --set-xmark 0x1/0xffffffff -p esp -m policy --dir in --pol ipsec --spi 0xc89f8130 -j MARK --set-xmark 0x1/0xffffffff -p esp -m policy --dir in --pol ipsec --reqid 1 -j MARK --set-xmark 0x1/0xffffffff -j LOG --log-prefix "mangle_PREROUTING: " Yet the packet did not get marked... I start to believe this is a bug. Regards, Steffen </pre> Steffen Heil (Mailinglisten 2012-05-18T09:35:42 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44483 <pre>Hi! The Netfilter project proudly presents: libnetfilter_conntrack 1.0.1 libnetfilter_conntrack is a userspace library providing a programming interface (API) to the in-kernel connection tracking state table. This library is currently used by conntrack-tools among many other applications. This release includes important improvements for the expectation support. See ChangeLog that comes attached to this email for more details. You can download it from: http://www.netfilter.org/projects/libnetfilter_conntrack/downloads.html ftp://ftp.netfilter.org/pub/libnetfilter_conntrack/ Have fun! Kelvie Wong (1): expect: support NFCT_Q_CREATE_UPDATE in nfexp_query Pablo Neira Ayuso (15): expect: add XML support for nfexp_snprintf() expect: add class support expect: add NAT support expect: add expectfn support expect: CTA_EXPECT_HELP_NAME must be NULL-terminated expect: fix comparison of expectation class and flags expect: fix missing whitespace after expectation flags in nfexp_snprintf conntrack: add support for CTA_MARK_MASK and filtered dumping qa: add some stress tools to test conntrack via ctnetlink qa: several improvements for the ct_stress tools conntrack: fix wrong building of ICMP reply tuple conntrack: add new ATTR_GRP_[ORIG|REPL]_ADDR_[SRC|DST] attribute conntrack: fix new ATTR_GRP_[ORIG|REPL]_ADDR_[SRC|DST] qa: add test case for get/set ATTR_GRP_* API build: bump version to 1.0.1 </pre> Pablo Neira Ayuso 2012-05-18T00:35:47 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44482 <pre>BTW, if that helps, here is some information about my systems. (Ubuntu 12.04 LTS Precise Pangolin, currently virtual, 64bit, fully updated.) root&lt; at &gt;vpn-a:~# iptables --version iptables v1.4.12 root&lt; at &gt;vpn-a:~# uname -a Linux vpn-a 3.2.0-24-virtual #37-Ubuntu SMP Wed Apr 25 10:17:19 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux root&lt; at &gt;vpn-a:~# lsmod Module Size Used by xt_policy 12670 1 xt_esp 12529 0 iptable_mangle 12734 1 xt_mark 12563 2 ip_tables 27473 1 iptable_mangle x_tables 29846 5 xt_policy,xt_esp,iptable_mangle,xt_mark,ip_tables authenc 17582 2 xfrm6_mode_tunnel 12639 2 xfrm4_mode_tunnel 12639 4 xfrm_user 31825 2 xfrm4_tunnel 12779 0 tunnel4 13213 1 xfrm4_tunnel ipcomp 12673 0 xfrm_ipcomp 13556 1 ipcomp esp4 17061 2 ah4 12885 0 deflate 12617 0 zlib_deflate 27139 1 deflate ctr 13201 0 twofish_generic 16635 0 twofish_x86_64_3way 25287 0 twofish_x86_64 12867 1 twofish_x86_64_3way twofish_common 20919 3 twofish_generic,twofish_x86_64_3way,twofish_x86_64 camellia 29348 0 serpent 29125 0 blowfish_generic 12530 0 blowfish_x86_64 21466 0 blowfish_common 16699 2 blowfish_generic,blowfish_x86_64 cast5 25112 0 des_generic 21415 0 xcbc 12815 0 rmd160 16744 0 sha512_generic 12796 0 crypto_null 12918 0 af_key 36389 0 xfs 836508 1 </pre> Steffen Heil (Mailinglisten 2012-05-17T20:39:07 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44481 <pre>Hi again, Lots of experiments later, but still no luck.... it. I did. And I tried # echo "7 7 7 7" &gt; /proc/sys/kernel/printk Nothing appears on `dmesg`. Also I noticed that xt_esp was not loaded automatically. I had to load it using `insmod`. Still no output. But note, that I could not use -m esp --espspi either, see below. -m esp --espspi XXXXX Or -m polixy --spi XXXXX --dir in The later does not match, but I cannot even get the former one to be accepted: # iptables -t mangle -D PREROUTING -p esp -m esp --espspi 0xcde0e1ca -j MARK --set-mark 1 iptables: No chain/target/match by that name. # iptables -t mangle -D PREROUTING -p esp --espspi 0xcde0e1ca -j MARK --set-mark 1 iptables: No chain/target/match by that name. # iptables -t mangle -D PREROUTING -m esp --espspi 0xcde0e1ca -j MARK --set-mark 1 iptables: No chain/target/match by that name. Is there a way to find out what's wrong here? value) --espspi does not work at all - iptables complains, see above. Also, I tried -m polixy --spi XXXX -dir in for all spi codes I could find anywhere - it never matched.. BTW: If matching the SPI is a problem, I would prefer matching reqid anyway. But for now it would suffice to match any of those. I am really stuck here. Any hints are still welcome. Also I would be glad, if I could chat with someone using msn messenger or mirc or anything. I could also provide ssh root access to these machines... Regards, Steffen </pre> Steffen Heil (Mailinglisten 2012-05-17T20:15:13 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44480 <pre>Hi I'm trying to work out what I guess might not be possible with iptables or is simple and I"m just missing something I have 3 devices on the same subnet 192.168.0.1 ADSL Router 192.168.0.240 Linux Server 192.168.0.100 Windows PC The Linux server has no rules and ACCEPT on all What would the minimum necessary rule(s) to get the Linux Server to forward (with SNAT or MASQUERADE) packets through the Router from 192.168.0.100 and also send the replies back? The Linux Server has 192.168.0.1 as it's gateway and also has ip forwarding enabled I set the gateway on the windows PC to 192.168.0.240 I tried a few simple single rules and failed. (Just the single rule and deleted it after) 2 examples were: iptables -t nat -A POSTROUTING -o br0 -s 192.168.0.0/24 ! -d 192.168.0.0/24 -j SNAT --to 192.168.0.240 iptables -t nat -A POSTROUTING -o br0 -s 192.168.0.0/24 -j SNAT --to 192.168.0.240 Single ping shows: 192.168.0.100 -&gt; 74.125.237.113 192.168.0.240 -&gt; 74.125.237.113 74.125.237.113 -&gt; 192.168.0.240 but no "74.125.237.113 -&gt; 192.168.0.100" tcpdump: 09:48:57.726511 IP 192.168.0.100 &gt; 74.125.237.113: ICMP echo request, id 512, seq 4608, length 40 0x0000: 4500 003c ba86 0000 8001 873f c0a8 0064 0x0010: 4a7d ed71 0800 395c 0200 1200 6162 6364 0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 0x0030: 7576 7761 6263 6465 6667 6869 09:48:57.726511 IP 192.168.0.100 &gt; 74.125.237.113: ICMP echo request, id 512, seq 4608, length 40 0x0000: 4500 003c ba86 0000 8001 873f c0a8 0064 0x0010: 4a7d ed71 0800 395c 0200 1200 6162 6364 0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 0x0030: 7576 7761 6263 6465 6667 6869 09:48:57.726547 IP 192.168.0.240 &gt; 74.125.237.113: ICMP echo request, id 512, seq 4608, length 40 0x0000: 4500 003c ba86 0000 7f01 87b3 c0a8 00f0 0x0010: 4a7d ed71 0800 395c 0200 1200 6162 6364 0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 0x0030: 7576 7761 6263 6465 6667 6869 09:48:57.726550 IP 192.168.0.240 &gt; 74.125.237.113: ICMP echo request, id 512, seq 4608, length 40 0x0000: 4500 003c ba86 0000 7f01 87b3 c0a8 00f0 0x0010: 4a7d ed71 0800 395c 0200 1200 6162 6364 0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 0x0030: 7576 7761 6263 6465 6667 6869 09:48:57.758816 IP 74.125.237.113 &gt; 192.168.0.240: ICMP echo reply, id 512, seq 4608, length 40 0x0000: 452c 003c 8913 0000 3801 fffa 4a7d ed71 0x0010: c0a8 00f0 0000 415c 0200 1200 6162 6364 0x0020: 6566 6768 696a 6b6c 6d6e 6f70 7172 7374 0x0030: 7576 7761 6263 6465 6667 6869 Anyone know what it should really be (or if it isn't possible why?) Thanks for your help. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Andrew 2012-05-17T16:18:26 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44479 <pre>Hi, "iptable stop" got hung in the server, so I killed that process. But still there is a modprobe process running there, that I can't kill. oot 13834 99.8 0.0 3884 596 ? R 11:15 132:39 /sbin/modprobe -q -r ipt_state ip_nat_ftp iptable_nat xt_NOTRACK ip_conntrack_ftp ip_conntrack_netbios_ns xt_connlimit ip_conntrack ipt_recent This is what I can see in dmesg http://pastebin.com/BxEsyByC --Unni -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Unni 2012-05-17T13:30:35 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44477 <pre>Thanks a lot Wento !! for your time and information provided On Wed, May 16, 2012 at 4:02 PM, Wentao Shang &lt;wentaoshang&lt; at &gt;gmail.com&gt; wrote: </pre> Sudheer 2012-05-16T10:38:27 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44476 <pre>You may call nfq_create_queue() several times and specify each queue with different number (the 2nd param in the function) and different callback routine. However, I'm not sure how the incoming packets are delivered to different queues. Maybe you should use select() or poll() here. Wentao 2012/5/16 Sudheer &lt;sudheer.d&lt; at &gt;oneconvergence.com&gt;: </pre> Wentao Shang 2012-05-16T10:32:54 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44475 <pre>Hi, Is there any plans to release the version 2 of ulog ? It would be nice it is included in Wheezy version of Debian, which must be frozen soon. Thanks ! Benoît. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> SPONEM, Benoît 2012-05-16T09:20:05 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44474 <pre> On Wednesday 2012-05-16 08:34, Steffen Heil (Mailinglisten) wrote: sysctl -w kernel.printk="7 7 7 7" is probably one way. It is not unusual to see `ip -s x p` showing spi 0. About setkey I don't know, since openswan and I don't use that. Better trust `ip x s`. Also note that there may be a handful of SPIs live between peers, not just a single one. --espspi per manpage. Your command does not match your output. See dmesg. (Well, it told you that.) Why don't you try --espspi 0xc4b51d18 for a change, since that is (one value) from those obtained from ip x s. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Jan Engelhardt 2012-05-16T06:51:04 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44473 <pre>Hi , I am new to the concept of netfilters so i have downloaded the "nfqnl_test.c" from the website and compiled it. Could you please let me know how to run this code and check the output. Do we need to execute any others commands before running this code ?? It will be very useful for me if you let me know the procedure to use the "nfqnl_test.c" code. </pre> Sudheer 2012-05-16T06:45:40 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44472 <pre>Hi First, thanks for the answer, but I am stuck with those: How would I do so? I never used sysctl for anything but enabling ip forwarding.... Second: Below is the current output of `ip -s xfrm policy`, `ip -s xfrm sate` and `setkey -D`. I noticed, - `ip -s xfrm policy` contains "proto esp spi 0x00000000(0)". - `setkey -D` contains "spi=3243547107(0xc15499e3)". - `ip -s xfrm state` contains "esp spi 0xc4b51d18(3300203800)". Is this to be expected? Third, I tried you command: # iptables -t mangle -A PREROUTING -p esp --spi 0xcdfebb11 -j MARK --set-mark 1 iptables v1.4.12: Gives: unknown option "--spi" # iptables -t mangle -A PREROUTING -p esp -m espspi --spi 0xcdfebb11 -j MARK --set-mark 1 iptables v1.4.12: policy match: neither --dir in nor --dir out specified # iptables -t mangle -A PREROUTING -p esp -m policy --spi 0xcdfebb11 --dir out -j MARK --set-mark 1 iptables: Invalid argument. Run `dmesg' for more information. # iptables -t mangle -A PREROUTING -p esp -m policy --spi 0xcdfebb11 --dir in -j MARK --set-mark 1 That worked, however I still don't get the packets through. Because of the different spi information mentioned above, I also tried: # iptables -t mangle -A PREROUTING -p esp -m policy --spi 0xcdfebb11 --dir in -j MARK --set-mark 1 Same result: Accepted but not matched. I can still get it to work removing the conditions, so everything else is fine: # iptables -t mangle -A PREROUTING --proto esp -j MARK --set-mark 1 I am still stuck and very thankful for every hint... Regards, Steffen # setkey -D 10.5.0.1 10.5.0.2 esp mode=tunnel spi=3243547107(0xc15499e3) reqid=1(0x00000001) E: aes-cbc 49e40f42 d0df7e1e 7202ad2e c45110bd A: hmac-sha1 afa4eefd b81a952d 68f9cf88 3287715b 3d4ae624 seq=0x00000000 replay=32 flags=0x00000000 state=mature created: May 16 06:02:36 2012 current: May 16 06:16:15 2012 diff: 819(s) hard: 1200(s) soft: 896(s) last: May 16 06:12:04 2012 hard: 0(s) soft: 0(s) current: 21168(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 252 hard: 0 soft: 0 sadb_seq=1 pid=11397 refcnt=0 10.5.0.2 10.5.0.1 esp mode=tunnel spi=3456023313(0xcdfebb11) reqid=1(0x00000001) E: aes-cbc d5bcb28b 0378d65a 97ac2757 1afa6ff8 A: hmac-sha1 1eeb8605 db1f4cc9 c3a4dc22 1a3306d2 b9928a9c seq=0x00000000 replay=32 flags=0x00000000 state=mature created: May 16 06:02:36 2012 current: May 16 06:16:15 2012 diff: 819(s) hard: 1200(s) soft: 1014(s) last: May 16 06:12:04 2012 hard: 0(s) soft: 0(s) current: 2100(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 25 hard: 0 soft: 0 sadb_seq=0 pid=11397 refcnt=0 # ip -s xfrm policy src 10.2.1.0/24 dst 10.1.1.0/24 uid 0 dir fwd action allow index 1530 priority 1859 share any flag (0x00000000) lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2012-05-16 06:16:40 use - mark 1/0xffffffff tmpl src 10.5.0.2 dst 10.5.0.1 proto esp spi 0x00000000(0) reqid 1(0x00000001) mode tunnel level required share any enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff src 10.2.1.0/24 dst 10.1.1.0/24 uid 0 dir in action allow index 1520 priority 1859 share any flag (0x00000000) lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2012-05-16 06:16:40 use - mark 1/0xffffffff tmpl src 10.5.0.2 dst 10.5.0.1 proto esp spi 0x00000000(0) reqid 1(0x00000001) mode tunnel level required share any enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff src 10.1.1.0/24 dst 10.2.1.0/24 uid 0 dir out action allow index 1513 priority 1859 share any flag (0x00000000) lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 0(sec), hard 0(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2012-05-16 06:16:40 use 2012-05-16 06:24:57 mark 1/0xffffffff tmpl src 10.5.0.1 dst 10.5.0.2 proto esp spi 0x00000000(0) reqid 1(0x00000001) mode tunnel level required share any enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff # ip -s xfrm state src 10.5.0.1 dst 10.5.0.2 proto esp spi 0xc4b51d18(3300203800) reqid 1(0x00000001) mode tunnel replay-window 32 seq 0x00000000 flag af-unspec (0x00100000) mark 1/0xffffffff auth-trunc hmac(sha1) 0x597784c0a0905a2346a797daaa79145e17b1a2ca (160 bits) 96 enc cbc(aes) 0xd44a6ec5f13010267a2d145f9564b75e (128 bits) lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 884(sec), hard 1200(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 49476(bytes), 589(packets) add 2012-05-16 06:16:40 use 2012-05-16 06:16:41 stats: replay-window 0 replay 0 failed 0 src 10.5.0.2 dst 10.5.0.1 proto esp spi 0xc2f9a112(3271139602) reqid 1(0x00000001) mode tunnel replay-window 32 seq 0x00000000 flag af-unspec (0x00100000) mark 1/0xffffffff auth-trunc hmac(sha1) 0x98af746b619e7d723696b2f67fc46a127fde097a (160 bits) 96 enc cbc(aes) 0xef5b3d9a4a0cb8c9cc9787dbba0c7c9c (128 bits) lifetime config: limit: soft (INF)(bytes), hard (INF)(bytes) limit: soft (INF)(packets), hard (INF)(packets) expire add: soft 907(sec), hard 1200(sec) expire use: soft 0(sec), hard 0(sec) lifetime current: 0(bytes), 0(packets) add 2012-05-16 06:16:40 use - stats: replay-window 0 replay 0 failed 0 </pre> Steffen Heil (Mailinglisten 2012-05-16T06:34:56 http://permalink.gmane.org/gmane.comp.security.firewalls.netfilter.general/44471 <pre> On Wednesday 2012-05-16 00:44, Steffen Heil (Mailinglisten) wrote: xt_esp generates debug output if you have "printk" sysctl set to show it. -t mangle -A PREROUTING -p esp --spi 0xc480f134 -j MARK --set-mark 1 -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo&lt; at &gt;vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html </pre> Jan Engelhardt 2012-05-15T23:23:09 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.firewalls.netfilter.general