ipfw nat drops icmp packets from localhost

2011-10-06 Thread Oleg Strizhak 

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

2011-10-06 Thread Oleg Strizhak 

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]

2011-10-06 Thread Oleg Strizhak 

Здравствуйте, 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

2011-10-06 Thread Alexander V. Chernikov 
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

___