kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet

[Ian Smith]

On Wed, 2 Jun 2010, Jose M Rodriguez wrote:
 > The following reply was made to PR kern/147191; it has been noted by GNATS.
 > 
 > From: Jose M Rodriguez <josemi at freebsd.jazztel.es>
 > To: bug-followup at FreeBSD.org
 > Cc:  
 > Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet
 > Date: Wed, 02 Jun 2010 04:31:49 +0200
[..]
 >  El 02/06/2010 2:37, Jose M Rodriguez escribió:
 >  > Seems that this must be reopen.
 >  > ...
 >  Seems this one worked, but I don't remember this last time I use ipfw on 
 >  FreeBSD-7
 >  
[..]
 >  Content-Disposition: attachment;
 >   filename="rc.firewall.router.4"
 >  
 >  #!/bin/sh -
 >  # Copyright (c) 1996  Poul-Henning Kamp
 >  # All rights reserved.
[..]
 >  # $FreeBSD: src/etc/rc.firewall,v 1.60.2.3 2010/04/14 15:03:58 ume Exp $

I had to do a 'diff -uw rc.firewall.1.60.2.3 rc.firewall.router.4' (and 
before that, vs your previous rc.firewall.router.1) to follow what was 
going on here; you've added some 'interesting' stuff (esp dummynet), but 
I think your main problem is the placement of the NAT rule, where you've 
merged it into what is otherwise based on the 'workstation' ruleset.

Refer to the standard rc.firewall 'simple' ruleset: note carefully that 
there the NAT diversion occurs between two sets of anti-spoofing rules, 
such that we have, in effect, for both inbound and outbound packets:

1)	deny all from any to $RFC1918_etc_nets via ${oif}

2)	# perform NAT (by natd or ipfw nat)

3)	deny all from $RFC1918_etc_nets to any via ${oif}

You've used a table for these nets, great, but in the following rules 
you are doing step (3) _before_ doing NAT, likely blocking some packets 
before they've been mapped to your outside IP address.  I think this may 
be why you then had to handle local net traffic later, and also that 
this will affect your shaping rules similarly, as you mentioned earlier.

I believe julian@ first proposed changing rc.firewall to use a table 
with two rules rather than bunches of individual rules, here:

http://lists.freebsd.org/pipermail/freebsd-ipfw/2008-November/003661.html

but you'll notice he maintained the correct positioning of these rules.

You have:

 >  # rfc 1912 local net
 >  ${fwcmd} table ${astable} add 0.0.0.0/8		${asln} # this network
 >  ${fwcmd} table ${astable} add 127.0.0.0/8	${asln} # local net
 >  ${fwcmd} table ${astable} add 255.0.0.0/8	${asln} # local net
 >  # rfc 1918 private nets
 >  ${fwcmd} table ${astable} add 10.0.0.0/8	${aspn} # private net
 >  ${fwcmd} table ${astable} add 172.16.0.0/12	${aspn} # private net
 >  ${fwcmd} table ${astable} add 192.168.0.0/16	${aspn} # private net

etc, then ..

 >  # anti spoofing
 >  ${fwcmd} add deny all from table\(${astable}\) to any recv ${oif}
 >  ${fwcmd} add deny all from any to table\(${astable}\) xmit ${oif}

but only later, after all your dummynet rules, do you either skipto 
30000, or skipto your queue rules then skipto 30000, where you at last 
perform the NAT translation, which should already have been done.

Further, your anti-spoofing rules, the second of which should be before 
doing NAT but the first _after_ doing NAT, are one case where using 
'via' rather than recv/xmit is appropriate, as you want to block these 
nets on egress from your router as well as on ingress, right?

I suspect that if you weave your NAT diversion into the right place 
(sooner) and place the anti-spoofing rules properly either side, things 
should work more as you expect.  Maybe add some more temporary logging 
rules to check what's happening before and after NAT mapping?

cheers, Ian