Re: pf + enc

[Cedric Berger <cedric@wireless-networks.com>]

Daniel Hartmeier wrote:

>On Wed, Jul 17, 2002 at 11:21:27AM -0500, glaive@vaned.net wrote:
>
>  
>
>>although this does not work.  (despite including filters in the isakmp
>>policy file, and the flows being configured a certain way i'm assuming
>>no enforcement is done on encapsulated addresses going through the vpn?)
>>    
>>
>
>Yes, for some reason (I haven't investigated it fully yet), some packets
>will go through the enc interface still encapsulated (probably they are
>encapsulated in multiple layers). The important point is that they will
>pass through enc for each layer, so it's enough to block unwanted
>packets on any of those passes. So, just allow the outer layer (which is
>probably just from/to the tunnel endpoints) with two additional rules
>(allowing the encapsulation protocol), and the filter policy on the
>innermost protocol will still be enforced.
>
>If someone has a more detailed analysis of this case, please let me
>know, so the pf example rules in the vpn man page can be adjusted.
>
Yes, you need to add:

   "pass in quick on enc0 proto ipencap all"

For *encapsulated* packet (i.e tunnel mode IPsec, but it is not needed 
for transport mode IPsec)
Also this is only required for input packet, there is no need to put a 
"pass out" rule. This is because
on reception, the handling of encapsulated packets is done with 3 
roundtrip inside the IP input
code path.
 - 1st time with them ESP packet
 - 2nd time with the cleartext encapsulated packet
 - 3rd time with the decapsulated packet.

On the output path, uncapsulation and encryption are done in a single step,
so PF is only called with the original decapsulated packet and the final
ESP packet.

This is not the best possible design, but if you know what to do, it works.
There is also a chicked-or-egg-first problem when handling rules like
"nat on enc0" or "rdr on enc0", which could only be solved properly by
having the NAT code talking with the IPSec policy layer for deciding
if an outgoing packet should or shouldn't be nat'd.

I tried to implement that with OpenBSD 2.9, but IPF what such a mess to
understand that I gave up. I might do that now that PF is "readable" and
"integrated" with OpenBSD.

If you have any question with the interactions between (I)PF and IPSec,
feel free to ask since I've looked at that pretty extensively...

Cedric