NAT broken in -CURRENT

[Julian Elischer]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"