Re: kern/122109: [ipfw] ipfw nat traceroute problem

2011-06-03 Thread Alexander V. Chernikov
The following reply was made to PR kern/122109; it has been noted by GNATS.

From: Alexander V. Chernikov melif...@ipfw.ru
To: bug-follo...@freebsd.org, m.dyadche...@211.ru, a...@freebsd.org
Cc:  
Subject: Re: kern/122109: [ipfw] ipfw nat traceroute problem
Date: Fri, 03 Jun 2011 10:08:13 +0400

 Problem is actually a bit deeper.
 
 Before libalias-based kernel nat appears natd uses PKT_ALIAS_IGNORE
 retrun code to drop packets iff PKT_ALIAS_DENY_INCOMING flag is set:
 
status = LibAliasIn (mla, buf, IP_MAXPACKET);
 if (status == PKT_ALIAS_IGNORED 
 mip-dropIgnoredIncoming) {
 
 if (verbose)
 printf ( dropped.\n);
 
 
 Current ipfw nat (and ng_nat) implementation simply drops every packet
 with PKT_ALIAS_IGNORE return code:
 
if (retval != PKT_ALIAS_OK 
retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) {
 /* XXX - should i add some logging? */
 m_free(mcl);
 
 Most of PKT_ALIAS_IGNORED are returned in case of no state is found (the
 rest are some (possibly) very rare unknown errors/handlers error).
 
 Libalias automatically create new state for every packet not found in
 aliasing database if it reasonable to do so (TCP/UDP packets is
 definitely reasonable since they represent logical sessions, icmp
 req/reply is reasonable too, etc..). On the opposite, there is no reason
 for creating state for packets signaling some existing session errors
 (icmp unreach, etc..) since such packets are rare/unidirectional and no
 reply is needed.
 
 The only 2 places states are not created (not mentioning
 PKT_ALIAS_PROXY_ONLY and PKT_ALIAS_DENY_INCOMING modes) are
 IcmpAliasIn2()|IcmpAliasOut2() functions.
 
 Those function dispatches various ICMP notification and tries to map
 those notification to existing states using original packet header
 within ICMP message. If such session is not found (PR case, since
 usually locally-originated packets are not passed to libalias and no
 replies are transmitted due to traceroute specific) return code is set
 to PKT_ALIAS_IGNORED.
 
 As a result: restoring original behavior should not break anything.
 
 This patch seems to fix the problem:
 
 Index: ip_fw_nat.c
 ===
 --- ip_fw_nat.c (revision 221263)
 +++ ip_fw_nat.c (working copy)
 @@ -267,8 +267,9 @@
 m-m_flags |= M_SKIP_FIREWALL;
 retval = PKT_ALIAS_OK;
 }
 -   if (retval != PKT_ALIAS_OK 
 -   retval != PKT_ALIAS_FOUND_HEADER_FRAGMENT) {
 +   if (retval == PKT_ALIAS_ERROR || retval ==
 PKT_ALIAS_UNRESOLVED_FRAGMENT ||
 +   (retval == PKT_ALIAS_IGNORED 
 +(t-lib-packetAliasMode  PKT_ALIAS_DENY_INCOMING))) {
 /* XXX - should i add some logging? */
 m_free(mcl);
 args-m = NULL;
 
 
 Something similar should be applied to ng_nat.c
___
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: svn commit: r222582 - head/sys/netinet/ipfw

2011-06-03 Thread Vadim Goncharov
Hi Andrey V. Elsukov! 

On Wed, 1 Jun 2011 19:44:52 + (UTC); Andrey V. Elsukov a...@freebsd.org 
wrote:

 Log:
   O_FORWARD_IP is only action which depends from the result of lookup of
   dynamic rules. We are doing forwarding in the following cases:
o For the simple ipfw fwd rule, e.g.
   
   fwd 10.0.0.1 ip from any to any out xmit em0
   fwd 127.0.0.1,3128 tcp from any to any 80 in recv em1
   
o For the dynamic fwd rule, e.g.
   
   fwd 192.168.0.1 tcp from any to 10.0.0.3  setup keep-state
   
   When this rule triggers it creates a dynamic rule, but this
   dynamic rule should forward packets only in forward direction.
   
o And the last case that does not work before - simple fwd rule which
triggers when some dynamic rule is already executed.
[...]
   case O_FORWARD_IP:
   if (args-eh)   /* not valid on layer2 pkts */
   break;
 - if (!q || dyn_dir == MATCH_FORWARD) {
 + if (q == NULL || q-rule != f ||
 + dyn_dir == MATCH_FORWARD) {
   struct sockaddr_in *sa;
   sa = (((ipfw_insn_sa *)cmd)-sa);

The log is not clear in the purpose of the last case: it is used to make a
subroutine on the execution of dynamic rule instead of only one action
(it is clear only from both PRs which takes much time to grok rulesets).

Also, it is questionable whether this patch will stay correct in the future
when dynamic rules will be changed, and/or new opcodes (depending on packet
direction) are added. We should keep in mind this place for such future
changes now.

-- 
WBR, Vadim Goncharov. ICQ#166852181   mailto:vadim_nucli...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
___
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