Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Dec 2009 23:24:04 +0100
From:      Luigi Rizzo <rizzo@iet.unipi.it>
To:        Joe Marcus Clarke <marcus@marcuscom.com>
Cc:        luigi@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: NAT broken in -CURRENT
Message-ID:  <20091226222404.GA11164@onelab2.iet.unipi.it>
In-Reply-To: <alpine.BSF.2.00.0912261705180.87011@creme-brulee.marcuscom.com>
References:  <1261859138.1555.26.camel@shumai.marcuscom.com> <20091226212104.GA10498@onelab2.iet.unipi.it> <alpine.BSF.2.00.0912261705180.87011@creme-brulee.marcuscom.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 26, 2009 at 05:06:48PM -0500, Joe Marcus Clarke wrote:
> 
> 
> PGP Key : http://www.marcuscom.com/pgp.asc
> 
> On Sat, 26 Dec 2009, Luigi Rizzo wrote:
> 
> >On Sat, Dec 26, 2009 at 03:25:38PM -0500, Joe Marcus Clarke wrote:
> >...
> >>I updated my -CURRENT box yesterday.  After a reboot, NAT no longer
> >>works.  That is, if I have natd running with ipfw diverting packets to
> >>it, the box is a big black hole.  No packets leave.  I do see all
> >...
> >>I have a feeling the new ipfw code merged ~ 11 days ago is the cause of
> >>the problem.  Thinking that perhaps the new modularity is causing this
> >>problem, I also added the following two options to my kernel:
> >>
> >>options	IPFIREWALL_NAT
> >>options	LIBALIAS
> >>
> >>They did not help.  I have not tried using a purely modular ipfw/NAT
> >>combination, but I will attempt that later today.  I didn't see anything
> >>obvious in UPDATING.  Any suggestions, or any recommendations for
> >>specific troubleshooting data to capture?  Thanks.
> >
> >the changes were not expected to affect configuration or operation
> >so clearly i must have broken something in the reinjection process.
> >If you have a chance of looking at the ipfw counters (to see whether
> >packets are reinjected and where they end up) that would be helpful.
> >I'll try to run some tests here tomorrow or more likely on monday.
> 
> The packets appear to be looping to the divert socket.  The ipfw counters 
> show the divert rule is growing exponentially where as the other rules 
> have virtually no packet matches.  This is just after a few seconds of 
> uptime:

ok then try this change in netinet/ipfw/ip_fw2.c near line 1176

                                IPFW_RUNLOCK(chain);
                                return (IP_FW_DENY); /* invalid */
                        }
-                       f_pos = ipfw_find_rule(chain, skipto, 0);
+                       f_pos = ipfw_find_rule(chain, skipto+1, 0);
                }
        }

Let me know if it works so i can commit it.

cheers
luigi



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091226222404.GA11164>