tcpdump and ipsec

[Kelly Yancey]

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 at nttmcl.com