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>