Date: Fri, 6 Aug 2004 00:54:08 +0200 From: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl> To: freebsd-net@freebsd.org Subject: ipfilter/ipnat 3.4.35 and udp-traceroute problem Message-ID: <20040805225408.GA70729@shellma.zin.lublin.pl>
next in thread | raw e-mail | index | archive | help
Hello, Can anobody here confirm that newest 3.4.35 IPFilter in RELENG_4 works with no problems when IPNATing traceroute UDP (+ICMP response) packets? I can see weird behavior of this command: traceroute -s privateIP -P UDP dst Outgoing UDP packets are translated, ICMP time-exceded message comes back, but traceroute shows '* * *'. ;) Commands: traceroute -s privateIP -P ICMP dst and traceroute -s privateIP -P TCP dst are working OK. UDP protocol is _not_ filtered. Also `traceroute -s publicIP -P UDP dst' works just fine. State table was flushed and has low number of mappings: mapped in 167718594 out 162841788 added 4480473 expired 4466531 no memory 0 bad nat 375052 <- hm inuse 2259 <= rules 38 wilds 0 Mapping rules (for this uplink and this privateIP) are quite common: map rl0 privateIP/20 -> publicIP/32 proxy port ftp ftp/tcp map rl0 privateIP/20 -> publicIP/32 portmap tcp/udp auto map rl0 privateIP/20 -> publicIP/32 (/20 is big, but network is smaller, don't be scared). This ruleset was used for months with no problems. Kernel is almost GENERIC. Another interesting thing: % ipf -V ipf: IP Filter: v3.4.31 (336) <= Kernel: IP Filter: v3.4.35 [...] % grep -i ver /usr/src/contrib/ipfilter/ipl.h #define IPL_VERSION "IP Filter: v3.4.31" Newer ipl.h sits happily in vendor branch. -- Paweł Małachowski
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040805225408.GA70729>