ipfw nat drops icmp packets from localhost
Dear All! Would you mind enlightening me a little bit on the following: when I ping or traceroute any external host (even default gateway) w/o ipfw -- it's OK; when I ping -- w/ ipfw -- it's OK when I traceroute -- it FAILS =( all hop are three stars in a row when any LAN (192.168.0.х) host ping or traceroute any ext host (by ipfw nat) -- it's OK # uname -a FreeBSD proxy.yy.ru 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Mon Oct 3 19:19:30 MSD 2011 a...@xx.yy.ru:/usr/obj/usr/src/sys/ZZZ amd64 # ipfw nat show config ipfw nat 7 config if vr0 log same_ports reset redirect_port tcp 192.168.0.97:3389 7899 redirect_port tcp 192.168.0.250:3389 8998 redirect_port tcp 192.168.0.98:3389 7997 redirect_port tcp 192.168.0.201:3389 redirect_port tcp 192.168.0.254:3389 5995 redirect_port tcp 192.168.0.99:3389 9998 redirect_port tcp 192.168.0.95:3389 8899 redirect_port tcp 192.168.0.248:20-21 20-21 After an investigation I've found out a very strange situation - it seems to me, that ipfw nat drops some (type 11?) icmp reply packets, whose udp request packets it hasn't rewritten/seen before, e.g: 05577 count log logamount 1000 icmp from any to any 05600 nat 7 ip from any to me in { recv fxp0 or recv vr0 } 05677 count log logamount 1000 icmp from any to any if I ping (let's suppose that my external ip is 1.2.3.4 and dst ip is equal to 5.6.7.8, vr0 - external iface, fxp0 -- reserved external face, not used when vr0 is up running): Оct 6 11:47:40 proxy kernel: ipfw: 5577 Count ICMP:8.0 1.2.3.4 5.6.7.8 out via vr0 Oct 6 11:47:40 proxy kernel: ipfw: 5677 Count ICMP:8.0 1.2.3.4 5.6.7.8 out via vr0 Oct 6 11:47:40 proxy kernel: ipfw: 5577 Count ICMP:0.0 5.6.7.8 1.2.3.4 in via vr0 Oct 6 11:47:40 proxy kernel: ipfw: 5677 Count ICMP:0.0 5.6.7.8 1.2.3.4 in via vr0 if I traceroute: Oct 6 11:01:53 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.4 in via vr0 Oct 6 11:01:58 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.4 in via vr0 Oct 6 11:02:03 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.4 in via vr0 at the same time, if LAN host (yes, LAN's behind ale0) traceroutes ext host via nat 7: Oct 6 11:10:07 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.4 in via vr0 Oct 6 11:10:07 proxy kernel: ipfw: 5677 Count ICMP:11.0 5.6.7.8 192.168.0.97 in via vr0 Oct 6 11:10:07 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 192.168.0.97 out via ale0 Oct 6 11:10:07 proxy kernel: ipfw: 5677 Count ICMP:11.0 5.6.7.8 192.168.0.97 out via ale0 So, I wonder whether someone else has seen the same case under the similar circumstances? Isn't it a bug within ipfw nat module and is there any work-around/patch for that? I've surely googled, but in vain =( The only thing, that seems alike to my problem, is http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch didn't cure anything =( WBR, Oleg Strizhak ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: ipfw nat drops icmp packets from localhost
Hello, Andrey V. Elsukov! You wrote on 06.10.2011 at 13:38: On 06.10.2011 12:29, Oleg Strizhak wrote: After an investigation I've found out a very strange situation - it seems to me, that ipfw nat drops some (type 11?) icmp reply packets, whose udp request packets it hasn't rewritten/seen before, e.g: So, I wonder whether someone else has seen the same case under the similar circumstances? Isn't it a bug within ipfw nat module and is there any work-around/patch for that? I've surely googled, but in vain =( The only thing, that seems alike to my problem, is http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch didn't cure anything =( Can you describe how you did apply and test this patch? in a usual way =) Unfortunately, copy-pasted from the mentioned above page patch couldn't be applied w/ error: $ patch ~/ip_fw_nat.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- stable/8/sys/netinet/ipfw/ip_fw_nat.c Thu Jul 7 08:33:58 2011 (r223834) |+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c Thu Jul 7 09:29:11 2011 (r223835) -- Patching file ip_fw_nat.c using Plan A... patch: malformed patch at line 4: else the same results were obtained with combinations of -p5 -l and tail +2 ~/ip_fw_nat.patch options commands Finally, I modified the patch (which applies w/o a word =) a little bit w/o any difference to the original one: $ /usr/bin/diff -wBbu3 ~/ip_fw_nat.patch ~/ip_fw_nat.patch.my --- /root/ip_fw_nat.patch 2011-10-04 14:08:32.0 +0400 +++ /root/ip_fw_nat.patch.my2011-10-04 14:29:53.0 +0400 @@ -1,5 +1,5 @@ stable/8/sys/netinet/ipfw/ip_fw_nat.c Thu Jul 7 08:33:58 2011 (r223834) -+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c Thu Jul 7 09:29:11 2011 (r223835) +--- ip_fw_nat.c.orig 2010-12-21 20:09:25.0 +0300 ip_fw_nat.c2011-10-04 14:27:02.0 +0400 @@ -263,17 +263,27 @@ else retval = LibAliasOut(t-lib, c, then I recompiled the kernel, rebooted server and.. all is just the same =( WBR, Oleg ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: ipfw nat drops icmp packets from localhost [patch attached]
Здравствуйте, Andrey V. Elsukov! Вы писали 06.10.2011 13:38: On 06.10.2011 12:29, Oleg Strizhak wrote: After an investigation I've found out a very strange situation - it seems to me, that ipfw nat drops some (type 11?) icmp reply packets, whose udp request packets it hasn't rewritten/seen before, e.g: So, I wonder whether someone else has seen the same case under the similar circumstances? Isn't it a bug within ipfw nat module and is there any work-around/patch for that? I've surely googled, but in vain =( The only thing, that seems alike to my problem, is http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch didn't cure anything =( Can you describe how you did apply and test this patch? I beg your pardon: in my previous reply I forgot to attach my patch. Here it is WBR, Oleg --- ip_fw_nat.c.orig2010-12-21 20:09:25.0 +0300 +++ ip_fw_nat.c 2011-10-04 14:27:02.0 +0400 @@ -263,17 +263,27 @@ else retval = LibAliasOut(t-lib, c, mcl-m_len + M_TRAILINGSPACE(mcl)); - if (retval == PKT_ALIAS_RESPOND) { - m-m_flags |= M_SKIP_FIREWALL; - retval = PKT_ALIAS_OK; - } - if (retval != PKT_ALIAS_OK - retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) { + + /* +* We drop packet when: +* 1. libalias returns PKT_ALIAS_ERROR; +* 2. For incoming packets: +* a) for unresolved fragments; +* b) libalias returns PKT_ALIAS_IGNORED and +* PKT_ALIAS_DENY_INCOMING flag is set. +*/ + if (retval == PKT_ALIAS_ERROR || +(args-oif == NULL (retval == PKT_ALIAS_UNRESOLVED_FRAGMENT || +(retval == PKT_ALIAS_IGNORED +(t-lib-packetAliasMode PKT_ALIAS_DENY_INCOMING) != 0 { /* XXX - should i add some logging? */ m_free(mcl); args-m = NULL; return (IP_FW_DENY); } + + if (retval == PKT_ALIAS_RESPOND) +m-m_flags |= M_SKIP_FIREWALL; mcl-m_pkthdr.len = mcl-m_len = ntohs(ip-ip_len); /* ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: ipfw nat drops icmp packets from localhost
On 06.10.2011 14:42, Oleg Strizhak wrote: Hello, Andrey V. Elsukov! You wrote on 06.10.2011 at 13:38: On 06.10.2011 12:29, Oleg Strizhak wrote: After an investigation I've found out a very strange situation - it seems to me, that ipfw nat drops some (type 11?) icmp reply packets, whose udp request packets it hasn't rewritten/seen before, e.g: So, I wonder whether someone else has seen the same case under the similar circumstances? Isn't it a bug within ipfw nat module and is there any work-around/patch for that? I've surely googled, but in vain =( The only thing, that seems alike to my problem, is http://www.freebsd.org/cgi/query-pr.cgi?pr=129093, but the patch for 8 branch didn't cure anything =( Can you describe how you did apply and test this patch? in a usual way =) Unfortunately, copy-pasted from the mentioned above page patch couldn't be applied w/ error: svn diff -c 223835 svn://svn.freebsd.org/base/stable/8 ~/r223835.diff Can you try the patch attached (just to be sure) ? This is exact situation from this (and some related PRs) and this revision definitely fixes it. Btw, what is the value of net.inet.ip.fw.one_pass sysctl ? Are you sure that ipfw is the single enabled firewall on this machine ? Are you sure that system is using new kernel ? $ patch ~/ip_fw_nat.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- stable/8/sys/netinet/ipfw/ip_fw_nat.c Thu Jul 7 08:33:58 2011 (r223834) |+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c Thu Jul 7 09:29:11 2011 (r223835) -- Patching file ip_fw_nat.c using Plan A... patch: malformed patch at line 4: else the same results were obtained with combinations of -p5 -l and tail +2 ~/ip_fw_nat.patch options commands Finally, I modified the patch (which applies w/o a word =) a little bit w/o any difference to the original one: $ /usr/bin/diff -wBbu3 ~/ip_fw_nat.patch ~/ip_fw_nat.patch.my --- /root/ip_fw_nat.patch 2011-10-04 14:08:32.0 +0400 +++ /root/ip_fw_nat.patch.my2011-10-04 14:29:53.0 +0400 @@ -1,5 +1,5 @@ stable/8/sys/netinet/ipfw/ip_fw_nat.c Thu Jul 7 08:33:58 2011 (r223834) -+++ stable/8/sys/netinet/ipfw/ip_fw_nat.c Thu Jul 7 09:29:11 2011 (r223835) +--- ip_fw_nat.c.orig 2010-12-21 20:09:25.0 +0300 ip_fw_nat.c2011-10-04 14:27:02.0 +0400 @@ -263,17 +263,27 @@ else retval = LibAliasOut(t-lib, c, then I recompiled the kernel, rebooted server and.. all is just the same =( WBR, Oleg Index: sys/netinet/ipfw/ip_fw_nat.c === --- sys/netinet/ipfw/ip_fw_nat.c(revision 223834) +++ sys/netinet/ipfw/ip_fw_nat.c(revision 223835) @@ -263,17 +263,27 @@ else retval = LibAliasOut(t-lib, c, mcl-m_len + M_TRAILINGSPACE(mcl)); - if (retval == PKT_ALIAS_RESPOND) { - m-m_flags |= M_SKIP_FIREWALL; - retval = PKT_ALIAS_OK; - } - if (retval != PKT_ALIAS_OK - retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) { + + /* +* We drop packet when: +* 1. libalias returns PKT_ALIAS_ERROR; +* 2. For incoming packets: +* a) for unresolved fragments; +* b) libalias returns PKT_ALIAS_IGNORED and +* PKT_ALIAS_DENY_INCOMING flag is set. +*/ + if (retval == PKT_ALIAS_ERROR || + (args-oif == NULL (retval == PKT_ALIAS_UNRESOLVED_FRAGMENT || + (retval == PKT_ALIAS_IGNORED + (t-lib-packetAliasMode PKT_ALIAS_DENY_INCOMING) != 0 { /* XXX - should i add some logging? */ m_free(mcl); args-m = NULL; return (IP_FW_DENY); } + + if (retval == PKT_ALIAS_RESPOND) + m-m_flags |= M_SKIP_FIREWALL; mcl-m_pkthdr.len = mcl-m_len = ntohs(ip-ip_len); /* Property changes on: sys/contrib/pf ___ Modified: svn:mergeinfo Merged /head/sys/contrib/pf:r222806 Property changes on: sys/contrib/dev/acpica ___ Modified: svn:mergeinfo Merged /head/sys/contrib/dev/acpica:r222806 Property changes on: sys/cddl/contrib/opensolaris ___ Modified: svn:mergeinfo Merged /head/sys/cddl/contrib/opensolaris:r222806 Property changes on: sys/amd64/include/xen ___ Modified: svn:mergeinfo Merged /head/sys/amd64/include/xen:r222806 Property changes on: sys ___ Modified: svn:mergeinfo Merged /head/sys:r222806 ___