Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 04 Jun 2010 16:50:52 +0200
From:      Jose M Rodriguez <josemi@freebsd.jazztel.es>
To:        Ian Smith <smithi@nimnet.asn.au>
Cc:        freebsd-net@freebsd.org
Subject:   Re: kern/147191: [ppp] Problems with ppp -nat [pppoe], ipfw, dummynet
Message-ID:  <4C0912CC.8030807@freebsd.jazztel.es>
In-Reply-To: <20100603154510.T27982@sola.nimnet.asn.au>
References:  <201006020240.o522e3sU024508@freefall.freebsd.org> <20100603154510.T27982@sola.nimnet.asn.au>

next in thread | previous in thread | raw e-mail | index | archive | help
El 03/06/2010 9:15, Ian Smith escribió:
> 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.
>
>    
...
I don't have much experience doing ipfw setups, but I've setup docens of 
boxes with ipfilter. I don't think this maybe a 'rule' problem.
I expect two hits, one IN and other OUT, per IP packet.  But maybe this 
is NOT the case.
I do things as I learned to do:
- lo0
- local lans (big traffic, more simple)
- outside (less traffic, complex)

My initial setup (rc.firewall.router.4) uses ppp -nat, without natd. and 
one_pass=1 (without I Know). It mostly works, and I learn that I must 
setup one_pass=0 to get the packet again on ipfw after dummynet.

As I can read, this must also matters to ppp -nat. So I expect that a 
packed passed IN from local lan, after translated, hit the firewall as 
XMIT on tun0. I near sure this is not the case. Can anyone probe this?

So I must put the dummynet catching incoming traffic from lan to be 
translated later by ppp. This setup is NOW WORKING, with the sharper 
being effective and without problems with ppp -nat

rc.firewall.router.1 it's another history, after the problems with ppp, 
using mpd5 and natd.
I can't test this well, and the way things go are really odd, but this 
is how I get things mostly working.

What I noted on this setup is that I must pass the traffic incoming from 
local lan LAST, or NATP is not fuction at all (I use to do LAN traffic 
very first by performance reasons).

I begin to think in a libalias problem (inside natd this time), but I'm 
also in doubt about the two IN/OUT hits. Maybe there's only one hit as 
IN/OUT, as from a bridge hook?

In any case, the gotos (skipto) are placed not only as logic, but also 
to get counts of packets and try to see what's going on.

I know that the natd rule in not at the very first (/etc/rc.firewall use 
to put it as rule 25, even before 100 lo0.) but also near sure that no 
traffic that can matters natd (via oif, ng0) is passed or denied before 
that.  This matters about being able to catch incoming lan Traffic 
before translated.

This maybe my first test when I got time again.  Replace natd at rule 25 
and do again LAN traffic at FIRST. Also thinking in doing an altq/pf test.

And I added SOME line to my ipfw Notes:
- put dummynet VERY FIRST, if possible on INCOMING, and be sure that 
sysctl net.inet.ip.fw.one_pass=0.
- FreeBSD don't expect by default any firewall processing after libalias.

But now, I'm very busy, really
-- 
   josemi



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