ENC(4)

💅 ENC(4) 💅

okay bestie, welcome to the enc(4) page — it's from the Kernel Interfaces Manual, section 4, and it's literally the blueprint for the Encapsulating Interface. buckle up 🎀

---

✨ NAME ✨

enc — Encapsulating Interface 🦋

---

🌈 SYNOPSIS 🌈

so if you wanna bake this driver right into your kernel, drop this line into your kernel configuration file:

device enc

OR, if you'd rather load it as a module at boot time (main character move tbh), put this line in loader.conf(5):

if_enc_load="YES"

---

💖 DESCRIPTION 💖

k so the enc interface is a software loopback mechanism. what does that mean for you? it means hosts or firewalls get to filter ipsec(4) traffic using any firewall package that hooks in via the pfil(9) framework. no cap, any of them. 👑

the enc interface also lets an admin peek at incoming and outgoing packets before and after they will be or have been processed by ipsec(4) — and you do that with tcpdump(1). iconic.

the "enc0" interface inherits all IPsec traffic. so like. all IPsec traffic can be filtered based on "enc0", and all IPsec traffic could be seen by invoking tcpdump(1) on the "enc0" interface. it's giving everything, everywhere, all at once 💀

now — what can be seen with tcpdump(1) and what will be passed on to the firewalls via the pfil(9) framework can be independently controlled using these sysctl(8) variables:

• net.enc.out.ipsec_bpf_mask — default 0x00000003, suggested 0x00000001
• net.enc.out.ipsec_filter_mask — default 0x00000001, suggested 0x00000001
• net.enc.in.ipsec_bpf_mask — default 0x00000001, suggested 0x00000002
• net.enc.in.ipsec_filter_mask — default 0x00000001, suggested 0x00000002

(yeah that's the exact same table, just serving it in list form because we're cute like that 💅)

for the incoming path, a value of 0x1 means "before stripping off the outer header" and 0x2 means "after stripping off the outer header". for the outgoing path, 0x1 means "with only the inner header" and 0x2 means "with outer and inner headers". write that down, fr fr 📝

here's the whole flow, diagrammed:

incoming path                                          |------|
---- IPsec processing ---- (before) ---- (after) ----> |      |
                                                       | Host |
<--- IPsec processing ---- (after) ----- (before) ---- |      |
outgoing path                                          |------|

most people are gonna wanna run with the suggested defaults for ipsec_filter_mask and just rely on the security policy database for the outer headers. that's the vibe check ✅

⚠️ important note bestie: packets are captured by BPF before firewall processing. but there's a special value 0x4 you can configure in the ipsec_bpf_mask, and then packets will also be captured after firewall processing. obsessed with the flexibility honestly 😭

---

🌸 EXAMPLES 🌸

to see the packets the processed via ipsec(4) (yes, we're keeping that phrasing, it's part of the lore), adjust the sysctl(8) variables according to your need and run:

tcpdump -i enc0

and that's it. you're watching IPsec traffic like it's a livestream 🍓

---

👑 SEE ALSO 👑

tcpdump(1), bpf(4), ipf(4), ipfw(4), ipsec(4), pf(4)

---

and that's a wrap on the enc(4) page, bestie 🫶 this lil drop came from Debian, dated August 9, 2017 — so yeah, a classic, but a good one. go filter some packets, you absolute icon ✨💜