Date: Sat, 26 Dec 2009 14:28:30 -0800 From: Julian Elischer <julian@elischer.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: luigi@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: NAT broken in -CURRENT Message-ID: <4B368E0E.4070908@elischer.org> In-Reply-To: <20091226222404.GA11164@onelab2.iet.unipi.it> References: <1261859138.1555.26.camel@shumai.marcuscom.com> <20091226212104.GA10498@onelab2.iet.unipi.it> <alpine.BSF.2.00.0912261705180.87011@creme-brulee.marcuscom.com> <20091226222404.GA11164@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo wrote: > 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); yes the old code would look for the first rule with a rule number GREATER THAN the rule number of the divert rule that sent the packet out. (documented in divert and ipfw man pages I believe). > } > } > > Let me know if it works so i can commit it. > > cheers > luigi > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B368E0E.4070908>