Date: Thu, 3 Jun 2010 17:15:57 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Jose M Rodriguez <josemi@freebsd.jazztel.es> Cc: freebsd-net@freebsd.org Subject: Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet Message-ID: <20100603154510.T27982@sola.nimnet.asn.au> In-Reply-To: <201006020240.o522e3sU024508@freefall.freebsd.org> References: <201006020240.o522e3sU024508@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-1579116833-1275549357=:27982
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
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@freebsd.jazztel.es>
> To: bug-followup@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
--0-1579116833-1275549357=:27982--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100603154510.T27982>