[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: running PFIL_HOOKS on decapsulated IPsec packets, too [was: Re: reverse processing order: NAT, IPsec ?]
Greg A. Woods wrote:
At Fri, 26 Jun 2009 09:40:48 +0200 (CEST), Hubert Feyrer
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
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
The above would be used for *both* tunnel mode and transport mode
Main Index |
Thread Index |