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://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44496 <pre>Hi I have several SAs with the same networks and gateways on both sides but different xmarks (1 vs 2) and those work correctly. Therefor I need iptable rules like the following (in raw/PREROUTING): -p esp -m esp --espspi 0xc270c557 -j MARK --set-mark 1 -p esp -m esp --espspi 0xcaa7e5c8 -j MARK --set-mark 2 Then netfilter selects the correct SA. However, as the esp packets contain the spi value, I also expected them to work correctly if they have the same xmark (both 1): -p esp -m esp --espspi 0xc270c557 -j MARK --set-mark 1 -p esp -m esp --espspi 0xcaa7e5c8 -j MARK --set-mark 1 Yet, this does not work. I get the feeling that the selection of the correct SA is not based on the spi but on the ip and xmark only. This this true? If so, why? Isn't the SPI especially there for that reason? Can this be archived somehow? Best regards, Steffen </pre> Steffen Heil (Mailinglisten 2012-05-25T09:01:14 http://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.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://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44470 <pre>Hi I have the following problem. I have SAs that use firewall marks. So only packets that have that mark get encoded and decoded. I managed to set the mark for packets that shall be encoded but I cannot get the other side working. I have incoming packets that need to be decrypted and I need to set the correct mark for those. I CAN actually set the mark using the following command: iptables -t mangle -A PREROUTING --proto esp -j MARK --set-mark 1 BUT that rule matches ALL incoming esp packets. Yet I will have multiple SAs and I need to set different marks. I tried to use select by reqid or by spi, but as soon as I try that, the rule does not match anything any more. Can someone help me to get that iptables command right? Best regards, Steffen root&lt; at &gt;vpn-b:~# setkey -D 10.5.0.2 10.5.0.1 esp mode=tunnel spi=3296784692(0xc480f134) reqid=1(0x00000001) E: aes-cbc c5eb72ab 906d5717 67e405f5 cfe73f7a A: hmac-sha1 6935290e e51f0965 06577876 0d6237d6 45a0083d seq=0x00000000 replay=32 flags=0x00000000 state=mature created: May 15 22:23:06 2012 current: May 15 22:24:43 2012 diff: 97(s) hard: 1200(s) soft: 907(s) last: May 15 22:23:19 2012 hard: 0(s) soft: 0(s) current: 7140(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 85 hard: 0 soft: 0 sadb_seq=1 pid=8282 refcnt=0 10.5.0.1 10.5.0.2 esp mode=tunnel spi=3470192236(0xced6ee6c) reqid=1(0x00000001) E: aes-cbc e6fad1a5 ff31325b b4856748 c8997ea1 A: hmac-sha1 e401cc9d 59668c9f 866d7e86 b5a38d2c 1dcb2f2d seq=0x00000000 replay=32 flags=0x00000000 state=mature created: May 15 22:23:06 2012 current: May 15 22:24:43 2012 diff: 97(s) hard: 1200(s) soft: 888(s) last: May 15 22:23:19 2012 hard: 0(s) soft: 0(s) current: 7140(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 85 hard: 0 soft: 0 sadb_seq=0 pid=8282 refcnt=0 root&lt; at &gt;vpn-b:~# ip -s xfrm policy src 10.1.1.0/24 dst 10.2.1.0/24 uid 0 dir fwd action allow index 1218 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-15 22:08:11 use 2012-05-15 22:18:27 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 src 10.1.1.0/24 dst 10.2.1.0/24 uid 0 dir in action allow index 1208 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-15 22:08:11 use - 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 src 10.2.1.0/24 dst 10.1.1.0/24 uid 0 dir out action allow index 1201 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-15 22:08:11 use 2012-05-15 22:18:27 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 </pre> Steffen Heil (Mailinglisten 2012-05-15T22:44:56 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44469 <pre> Am really sorry i wrote so late about my inquiry i actually traveled to china to meet with some suppliers and i just came back into town few days ago. I was able to meet with some companies and also got to see what they have for me but i was surprised because the prices are much. We saw a similar product on Alibaba Shopping/Business page so please confirm to us if you/your company can make provision of the exact product as shown on Alibaba Shopping/Business page which you can view by clicking the link below and login with you email address together with your password to download the attachment page to view the product. Bellow is the link. http://dolbyltd.ucoz.com/plasltd.html We will await your response with details, date of delivery and send quotation for large qty urgently prize and quantity that can be made available. -- 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> dominick 2012-05-15T21:05:58 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44448 <pre>Hi, I'm playing with match modules limit and hashlimit, and they appear to be limited to match a maximun 100/sec. If I use hashlimit with no "--hashlimit-mode" I get the same, a max of 100/sec, even if I set for exemple to 250/sec. My command setting the 250/sec is accepted, with no error, but test show only 100 match/sec. Is this a hard limit of this modules, or I can go above this in some way? Best regards, Klaubert -- 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> Klaubert Herr da Silveira 2012-05-14T22:30:31 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44442 <pre>Hi all, I need to set rules for port forwarding/NAT on a clusterip-enabled node. I have this configuration: internal machine (A) -&gt; CLUSTER -&gt; external machine (B) I need to reach an UDP/TCP service on the external machine from an internal one (A). Is this feasible? Considering that clusterip nodes share a multicast mac address, seems that port forwarding can't be enabled due to impossibile multicast packet forwarding. I'm testing that setting one of the real IP of the cluster as gateway for node A, I'm able to reach node B; otherwise, using the clusterip address (associated with the multicast MAC) as gateway for the node A, node B is unreachable. Is there a way to to NAT through clusterip? Thank you, Michele De Candia -- 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> Michele De Candia 2012-05-14T16:09:04 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44441 <pre>  auth fedc299e subscribe netfilter mdecandia&lt; at &gt;gmail.com -- 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> Michele De Candia 2012-05-14T16:07:23 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44439 <pre>Hallo newsgroup members. my configuration is: &lt;= internet =&gt; eth0 [Linux Router NAT] eth1 &lt;=&gt; network behind the NAT: 192.168.10.0/24 Experience of end user sitting behind the NAT is that his browser after sending the request, waits on and on and page is never loaded. notebook_behind_the_NAT$ elinks www.bmw.com #just to remind: elinks is text browser. Linux_router$ sudo tcpdump -nN port 80 -i eth1 #eth1 - interface from nat side. tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 08:56:23.281011 IP 192.168.10.130.57196 &gt; 23.61.248.65.80: Flags [S], seq 2777447089, win 5840, options [mss 1460,sackOK,TS val 25390 ecr 0,nop,wscale 6], length 0 08:56:23.291543 IP 23.61.248.65.80 &gt; 192.168.10.130.57196: Flags [S.], seq 3924108416, ack 2777447090, win 14480, options [mss 1460,sackOK,TS val 650310770 ecr 25390,nop,wscale 2], length 0 08:56:23.291656 IP 192.168.10.130.57196 &gt; 23.61.248.65.80: Flags [.], ack 1, win 92, options [nop,nop,TS val 25393 ecr 650310770], length 0 08:56:23.291940 IP 192.168.10.130.57196 &gt; 23.61.248.65.80: Flags [P.], seq 1:194, ack 1, win 92, options [nop,nop,TS val 25393 ecr 650310770], length 193 08:56:23.303989 IP 23.61.248.65.80 &gt; 192.168.10.130.57196: Flags [.], ack 194, win 3888, options [nop,nop,TS val 650310782 ecr 25393], length 0 #Now I issued following "sudo cat /proc/net/ip_conntrack | grep 192.168" and closed browser. 08:56:30.602665 IP 192.168.10.130.57196 &gt; 23.61.248.65.80: Flags [F.], seq 194, ack 1, win 92, options [nop,nop,TS val 27220 ecr 650310782], length 0 08:56:30.654202 IP 23.61.248.65.80 &gt; 192.168.10.130.57196: Flags [.], ack 195, win 3888, options [nop,nop,TS val 650318129 ecr 27220], length 0 ^C 7 packets captured 7 packets received by filter 0 packets dropped by kernel #connection on port 80 is in ESTABLISHED state. udp/DNS messages work ok. #there is also ssh connection between Linux router and laptop behind the NAT, which works correct. Linux_router$ sudo cat /proc/net/ip_conntrack | grep 192.168 tcp 6 431994 ESTABLISHED src=192.168.10.1 dst=192.168.10.130 sport=33477 dport=22 src=192.168.10.130 dst=192.168.10.1 sport=22 dport=33477 [ASSURED] mark=0 use=2 tcp 6 431994 ESTABLISHED src=192.168.10.130 dst=23.61.248.43 sport=40200 dport=80 src=23.61.248.43 dst=89.77.223.114 sport=80 dport=40200 [ASSURED] mark=0 use=2 udp 17 24 src=192.168.10.130 dst=62.179.1.63 sport=35901 dport=53 src=62.179.1.63 dst=89.77.223.114 sport=53 dport=35901 mark=0 use=2 udp 17 24 src=192.168.10.130 dst=62.179.1.63 sport=44618 dport=53 src=62.179.1.63 dst=89.77.223.114 sport=53 dport=44618 mark=0 use=2 #dns and ping messages work ok. notebook_behind_the_NAT$ ping www.bmw.com PING a1550.b.akamai.net (23.61.248.65) 56(84) bytes of data. 64 bytes from a23-61-248-65.deploy.akamaitechnologies.com (23.61.248.65): icmp_seq=1 ttl=58 time=11.6 ms 64 bytes from a23-61-248-65.deploy.akamaitechnologies.com (23.61.248.65): icmp_seq=2 ttl=58 time=11.9 ms 64 bytes from a23-61-248-65.deploy.akamaitechnologies.com (23.61.248.65): icmp_seq=3 ttl=58 time=13.1 ms 64 bytes from a23-61-248-65.deploy.akamaitechnologies.com (23.61.248.65): icmp_seq=4 ttl=58 time=18.1 ms #now sniffing on public(internet) interface. This time I let finishing the session on its own. Linux_router$ sudo tcpdump -ttnN port 80 -i eth0 #. note: connection is finished after 120s. 1336636100.968299 IP 89.77.223.114.57208 &gt; 23.61.248.65.80: Flags [S], seq 671530171, win 5840, options [mss 1460,sackOK,TS val 804704 ecr 0,nop,wscale 6], length 0 1336636100.977786 IP 23.61.248.65.80 &gt; 89.77.223.114.57208: Flags [S.], seq 1270365566, ack 671530172, win 14480, options [mss 1460,sackOK,TS val 653428079 ecr 804704,nop,wscale 2], length 0 1336636100.977960 IP 89.77.223.114.57208 &gt; 23.61.248.65.80: Flags [.], ack 1, win 92, options [nop,nop,TS val 804707 ecr 653428079], length 0 1336636100.978239 IP 89.77.223.114.57208 &gt; 23.61.248.65.80: Flags [P.], seq 1:194, ack 1, win 92, options [nop,nop,TS val 804707 ecr 653428079], length 193 1336636100.989938 IP 23.61.248.65.80 &gt; 89.77.223.114.57208: Flags [.], ack 194, win 3888, options [nop,nop,TS val 653428091 ecr 804707], length 0 1336636221.102344 IP 89.77.223.114.57208 &gt; 23.61.248.65.80: Flags [F.], seq 194, ack 1, win 92, options [nop,nop,TS val 834737 ecr 653428091], length 0 What is worth mentioning, my hardware network setup works very well when Linux router works on ubuntu 11.04. Let's continue. #some iptbles facts Linux_router$ sudo iptables -L -nv Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Linux_router$ sudo iptables -tnat -L -nv Chain PREROUTING (policy ACCEPT 26 packets, 6168 bytes) pkts bytes target prot opt in out source destination Chain INPUT (policy ACCEPT 18 packets, 5640 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 6 packets, 334 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 14 862 MASQUERADE all -- * * 0.0.0.0/0 0.0.0.0/0 Linux_router$ iptables #version. iptables v1.4.12: no command specified Try `iptables -h' or 'iptables --help' for more information. #I also disabled ipv6 features (maybe not enough?). Linux_router$ sudo sysctl -p net.ipv4.ip_forward = 1 net.ipv6.conf.all.autoconf = 0 net.ipv6.conf.all.accept_ra = 0 net.ipv6.conf.all.disable_ipv6 = 1 #ipv6 address not present. Linux_router$ ifconfig eth0 Link encap:Ethernet HWaddr 00:18:8b:04:8a:13 inet addr:89.77.223.114 Bcast:255.255.255.255 Mask:255.255.252.0 UP BROADCAST RUNNING MULTICAST MTU:576 Metric:1 RX packets:8611 errors:12 dropped:0 overruns:0 frame:12 TX packets:1003 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:982765 (982.7 KB) TX bytes:97913 (97.9 KB) Interrupt:16 eth1 Link encap:Ethernet HWaddr 00:02:b3:8c:dc:e7 inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:126 errors:0 dropped:0 overruns:0 frame:0 TX packets:141 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:21024 (21.0 KB) TX bytes:15609 (15.6 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1184 (1.1 KB) TX bytes:1184 (1.1 KB) Linux_router$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 89.77.220.1 0.0.0.0 UG 100 0 0 eth0 89.77.220.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth1 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 0 eth1 I am stuck and I need Your help. best regards, Paul -- 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> Paul K 2012-05-14T08:25:49 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44435 <pre>Am really sorry i wrote so late about my inquiry i actually traveled to china to meet with some suppliers and i just came back into town few days ago. I was able to meet with some companies and also got to see what they have for me but i was surprised because the prices are much. We saw a similar product on Alibaba Shopping/Business page so please confirm to us if you/your company can make provision of the exact product as shown on Alibaba Shopping/Business page which you can view by clicking the link below and login with you email address together with your password to download the attachment page to view the product. Bellow is the link. http://sollanicsltd.ucoz.com/plasltd.html We will await your response with details, date of delivery and send quotation for large qty urgently prize and quantity that can be made available. -- 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> Tomm Frank 2012-05-14T08:17:34 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44420 <pre>WAIT YOUR URGENT REPLY Am really sorry i wrote so late about my inquiry i actually traveled to china to meet with some suppliers and i just came back into town few days ago. I was able to meet with some companies and also got to see what they have for me but i was surprised because the prices are much. We saw a similar product on Alibaba Shopping/Business page so please confirm to us if you/your company can make provision of the exact product as shown on Alibaba Shopping/Business page which you can view by clicking the link below and login with you email address together with your password to download the attachment page to view the product. Bellow is the link. http://sollanicsltd.ucoz.com/plasltd.html We will await your response with details, date of delivery and send quotation for large qty urgently prize and quantity that can be made available. Bestregard Tonny Frank -- 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> Tomm Frank 2012-05-13T23:06:02 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44418 <pre>haalloo, how are you doing,i hope you are fine,my name is miss abi okom i got your contact and want us to be a good friend, please try and write back to me so that i will give you my pictures and tell you more about me, -- 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> abi 2012-05-12T17:06:50 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44415 <pre>Hi all, I have setup the following rules in a centos6 gateway: Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 6 300 TCPFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 6 300 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- * * 224.0.0.0/4 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 224.0.0.0/4 0 0 DROP all -- * * 240.0.0.0/5 0.0.0.0/0 0 0 DROP all -- * * 0.0.0.0/0 10.196.129.255 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW icmp type 8 limit: avg 1/sec burst 1 0 0 SSH tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `IPT INPUT packet died: ' Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT all -- * * 172.24.50.3 0.0.0.0/0 state NEW 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `IPT FORWARD packet died: ' Chain OUTPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 6 300 TCPFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 6 300 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW,RELATED,ESTABLISHED 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `IPT OUTPUT packet died: ' Chain BADFLAGS (8 references) pkts bytes target prot opt in out source destination 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `IPT TCPFLAGS: ' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain SSH (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 1 0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix `IPT SSH connection too fast: ' 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 Chain TCPFLAGS (2 references) pkts bytes target prot opt in out source destination 0 0 LOG tcp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID LOG flags 0 level 4 prefix `IPT INVALID: ' 0 0 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 0 0 BADFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:!0x17/0x02 state NEW 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x12/0x12 state NEW reject-with tcp-reset 0 0 BADFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x11/0x01 0 0 BADFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x18/0x08 0 0 BADFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x30/0x20 0 0 BADFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x05/0x05 0 0 BADFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x03/0x03 0 0 BADFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x06 0 0 BADFLAGS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x3F/0x00 All works ok, except when I try to restrict one host to go out via external interface. My problem is with the following rule: 0 0 ACCEPT all -- * * 172.24.50.3 0.0.0.0/0 state NEW If I try to restrict destination, doesn't works. For example using this rule: iptables -A FORWARD -s 172.24.50.3 -d 1.1.1.0/24 -m state --state NEW -j ACCEPT only works if I do: iptables -A FORWARD -s 172.24.50.3 -m state --state NEW -j ACCEPT then, what am I doing wrong?? -- 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> C. L. Martinez 2012-05-11T15:04:51 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44413 <pre>Hi, In order to fix the build issue introduced in 6.12, a new ipset package version is released. Userspace changes: - Enable silent (kernel style) compile messages - Fix build failed on --disable-dependency-tracking (Neutron Soutmun) - Add tarball target to Makefile You can download the source code of ipset from: http://ipset.netfilter.org ftp://ftp.netfilter.org/pub/ipset/ git://git.netfilter.org/ipset.git Best regards, Jozsef - E-mail : kadlec&lt; at &gt;blackhole.kfki.hu, kadlecsik.jozsef&lt; at &gt;wigner.mta.hu PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences H-1525 Budapest 114, POB. 49, Hungary -- 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> Jozsef Kadlecsik 2012-05-10T20:19:50 http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.general/44391 <pre>nf_conntrack_l4proto.h is included twice. Signed-off-by: Eldad Zack &lt;eldad&lt; at &gt;fogrefinery.com&gt; --- net/netfilter/xt_CT.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c index 3746d8b..a51de9b 100644 --- a/net/netfilter/xt_CT.c +++ b/net/netfilter/xt_CT.c &lt; at &gt;&lt; at &gt; -17,7 +17,6 &lt; at &gt;&lt; at &gt; #include &lt;net/netfilter/nf_conntrack_l4proto.h&gt; #include &lt;net/netfilter/nf_conntrack_helper.h&gt; #include &lt;net/netfilter/nf_conntrack_ecache.h&gt; -#include &lt;net/netfilter/nf_conntrack_l4proto.h&gt; #include &lt;net/netfilter/nf_conntrack_timeout.h&gt; #include &lt;net/netfilter/nf_conntrack_zones.h&gt; </pre> Eldad Zack 2012-05-09T22:03:35 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.firewalls.netfilter.general