Date: Thu, 06 Oct 2011 12:29:54 +0400 From: Oleg Strizhak <oleg@pcbtech.ru> To: freebsd-ipfw@FreeBSD.org Subject: ipfw nat drops icmp packets from localhost Message-ID: <4E8D6702.9070707@pcbtech.ru>
next in thread | raw e-mail | index | archive | help
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=20
ipfw -- it's OK;
when I ping -"- w/ ipfw -- it's OK
when I traceroute -"- it FAILS =3D( all hop are three stars in a row
when any LAN (192.168.0.=C8) host ping or traceroute any ext host (by ipf=
w=20
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 aa@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 t=
cp 192.168.0.98:3389 7997 redirect_port tcp 192.168.0.201:3389 3333 redir=
ect_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=20
seems to me, that ipfw nat drops some (type 11?) icmp reply packets,=20
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=20
equal to 5.6.7.8, vr0 - external iface, fxp0 -- reserved external face,=20
not used when vr0 is up & running):
> =EFct 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=20
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.16=
8.0.97 in via vr0
> Oct 6 11:10:07 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 192.16=
8.0.97 out via ale0
> Oct 6 11:10:07 proxy kernel: ipfw: 5677 Count ICMP:11.0 5.6.7.8 192.16=
8.0.97 out via ale0
So, I wonder whether someone else has seen the same case under the=20
similar circumstances? Isn't it a bug within ipfw nat module and is=20
there any work-around/patch for that? I've surely googled, but in vain=20
=3D( The only thing, that seems alike to my problem, is=20
http://www.freebsd.org/cgi/query-pr.cgi?pr=3D129093, but the patch for 8=20
branch didn't cure anything =3D(
WBR,
Oleg Strizhak
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E8D6702.9070707>