Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Apr 2006 16:13:34 -0700 (PDT)
From:      Kelly Yancey <kbyanc@posi.net>
To:        "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
Cc:        Dmitry Pryanishnikov <dmitry@atlantis.dp.ua>, freebsd-net@freebsd.org, VANHULLEBUS Yvan <vanhu_bsd@zeninc.net>
Subject:   Re: tcpdump and ipsec
Message-ID:  <20060413155210.R73176@gateway.posi.net>
In-Reply-To: <20060411213528.F13011@maildrop.int.zabbadoz.net>
References:  <442D8E98.6050903@vineyard.net> <20060331222813.GA29047@zen.inc> <20060331223613.GD80492@spc.org> <20060402130227.G99958@atlantis.atlantis.dp.ua> <20060402113516.D76259@maildrop.int.zabbadoz.net> <20060402151039.R51461@atlantis.atlantis.dp.ua> <20060411153224.L55107@gateway.posi.net> <20060411213528.F13011@maildrop.int.zabbadoz.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 11 Apr 2006, Bjoern A. Zeeb wrote:

> On Tue, 11 Apr 2006, Kelly Yancey wrote:
>
> Hi,
>
> > On Sun, 2 Apr 2006, Dmitry Pryanishnikov wrote:
> >
> >> On Sun, 2 Apr 2006, Bjoern A. Zeeb wrote:
> >>>> Why not? IMHO it will be very useful feature: think about e.g. traffic
> >>>> shaping for several different networks which are routed via the same
> >>>> ipsec tunnel. Without the enc0, you can only shape them together, e.g.:
> >>>
> >>> why not shaping on the internal interface in case this is a gateway?
> >>> You know src and dst there too.
> >>
> >>   Gateway can also contain sources of traffic, and we should be able
> >> to shape all outgoing or incoming traffic (not only transit packets,
> >> but also locally-originated).
> >>
> >>> The only difference enc0 makes is for host-only-setups or if you want
> >>> to see all your unencrpyted ipsec traffic on a gateway in one place.
> >>
> >>   It seems to me that it's also useful for general traffic
> >> shaping/accounting/filtering purposes.
> >>
> >  I agree 100%.  At work, we implemented the enc interface for FreeBSD
> > 4.7 and 4.10 along with extending the divert interface such that we
> > could perform filtering and NAT on packets after tunnel decapsulation.
>
> you know you can do this with what's in there already w/o enc(4)?
> At least I have been doing it for more than two years now with 5.x
> and greater.  Actually this mail will get to you via such a setup.
>

  Really?  We aren't likely to move our product to 5.x or 6.x, but
I'm curious: how are you performing NAT on your tunnelled traffic?
  If we were just talking about filtering, I would assume you were
referring to the "ipsec" rule (which was introduced circa 4.9, hence not
available when we implemented the enc interface on 4.7).  However, I
cannot figure out for the life of me how one would perform NAT on
packets *inside* the IPsec tunnel without the enc interface.  For
example, the only pfil hook in the packet output path is is ip_output
*after* IPsec encapsulation has occurred.  Perhaps I'm missing
something.

>
> > Just because one person doesn't have a use for the enc interface, does
> > not mean that no one does.
>
> agreed.
>
> good arguments for example would also be that filtering IPSec traffic
> with pf would becomen possible easily as long as there is no such
> thing like the ipsec flag in ipfw...
>

  I'm really looking forward to hearing how you are diverting traffic to
natd before IPsec encapsulation.  Thanks,

  Kelly

-- 
Kelly Yancey  -  kbyanc@{posi.net,FreeBSD.org}  -  kelly@nttmcl.com



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