Re: if_enc(4) and net.inet.ipcomp.ipcomp_enable

On 2022-03-01 at 05:52 EST, Andrey V. Elsukov <bu7cher@yandex.ru> wrote:
>28.02.2022 02:54, Matteo Riondato пишет:
>>Hello net@,
>>
>>I am trying to use pf to filter packets in ipsec tunnels by filtering 
>>on enc0 from if_enc(4).
>>
>>I have the following values for the net.enc sysctl subtree: 
>>net.enc.out.ipsec_bpf_mask: 1
>>net.enc.out.ipsec_filter_mask: 1
>>net.enc.in.ipsec_bpf_mask: 2
>>net.enc.in.ipsec_filter_mask: 2
>>
>>and I have
>>
>>net.inet.ipsec.filtertunnel: 1
>>
>>Everything works well when the tunnel does not use ipcomp, but when it 
>>does, the incoming packets seem to ignore the value of the 
>>net.enc.in.ipsec_filter_mask sysctl, thus they show up in pf “twice”: 
>>once with both external and internall headers, and once only with 
>>internal (the value of 2 for this sysctl should make these packets 
>>show up only with internal headers). The same can be observed with 
>>tcpdump on enc0. This behavior makes it hard to do filtering.
>>
>>Is this behavior expected?

>are you sure that it is not just on ingress and egress? You can use -Q  
>flag for tcpdump to make sure.

Thank you for the suggestion, I realized I was just misinterpreting the 
output of tcpdump.

>The first time when you see IPcomp packet in PF, it is when it arrives 
>into IP stack on a physical interface (em, igb, ix, etc.). The second 
>time is after decompression on if_enc interface, it is called from 
>IPsec stack.

Are you sure about the above?

It seems to me (only by observing the effects of changing pf rules) 
that, with the net.enc sysctl values as above, the ipcomp packet is 
first seen by pf on if_enc, and then on the physical interface.

I should perhaps specify that by "ipcomp packets", I also mean the ipip 
packets that may go through the tunnel uncompressed because they are not 
large enough to warrant compression. I wonder whether the handling of 
ipip packets vs "real" ipcomp ones is different.

Thanks,
Matteo