Re: running PFIL_HOOKS on decapsulated IPsec packets, too [was: Re: reverse processing order: NAT, IPsec ?]

[Darren Reed <darrenr%netbsd.org@localhost>]

Greg A. Woods wrote:
> At Fri, 26 Jun 2009 09:40:48 +0200 (CEST), Hubert Feyrer 
> <hubert%feyrer.de@localhost> wrote:
> Subject: running PFIL_HOOKS on decapsulated IPsec packets, too [was: Re: 
> reverse processing order: NAT, IPsec ?]
> > 
> > On Thu, 25 Jun 2009, Greg A. Woods wrote:
> > > After seeing the ultimately simple fix Hubert posted to re-enable PFIL
> > > hooks for IPsec de-encapsulated packets I had a deja vu moment and I
> > > think I can say this silliness has caused problems in other contexts as
> > > well.
> > 
> > I don't understand - do you mean it's silly to run PFIL hooks on 
> > de-encapsulated packets?
>
> Sorry about the confusion.  No, it's silly not to run PFIL hooks on
> de-encapsulated IPsec packets.
>
> The problem though is of course that PFIL users must have some way to
> know that whether a packet has been de-encapsulated or not.
>   

A long time ago, my idea for this was to have decapsulated IPsec packets
appear (to pfil) to be on a different network interface to the encapsulated
ones. Thus while your ESP traffic comes in via fxp0, when the traffic is
decapsulated and reinjected on fxp0, PFIL_HOOKS would present that
to the hooks as being on ipsec.fxp0 (or something similar.) By presenting
the packets as belonging to a different interface, it is then straight 
forward
to write a rule set that applies the correct policy.

It might be worthwhile extending that idea further so that you can then
do "tcpdump -i ipsec.fxp0" to get a packet trace of only the unencrypted
packets.

The above would be used for *both* tunnel mode and transport mode
decapsulated packets.

Thoughts?

Darren