DIVERT(4)

📦
version 15.1 · 3 versions
, in freebsd 15.1

💅 DIVERT(4) — kernel packet diversion mechanism 🎀

okay so bestie, buckle up, this is the manual page for divert in the Kernel Interfaces Manual, and it's genuinely one of the coolest little tricks in the kernel. it lets a userspace program yoink packets out of the firewall mid-flight, do literally whatever to them, and shove them back in. main character energy fr.

✨ NAME ✨

divert — the kernel packet diversion mechanism. yes that's the whole name. iconic.

🦋 SYNOPSIS 🦋

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

int
socket(PF_DIVERT, SOCK_RAW, 0);

okay so to actually enable divert socket support, you gotta drop these lines into your kernel configuration file:

      options IPDIVERT

alternatively (the lazy-girl way, and honestly valid), you can load the driver as a module at boot time instead — just add these lines into the loader.conf(5) file:

      ipdivert_load="YES"

💖 DESCRIPTION 💖

Divert sockets let you intercept and re-inject packets flowing through the ipfw(4) and pf(4) firewalls. that's the whole vibe. 🫶

A divert socket can be bound to a specific divert port via the bind(2) system call. the sockaddr argument shall be sockaddr_in with sin_port set to the desired value. and before you ask: no, the divert port has nothing to do with TCP/UDP ports. it's just a cookie, and its value depends on which firewall you're using:

  • for ipfw(4) it's the number of the rule which diverted the packet
  • for pf(4) it's a value which indicates the original direction through the firewall of the diverted packet

A divert socket bound to a divert port will receive all packets diverted to that port by the firewall. and packets may also be written to a divert port, in which case they re-enter firewall processing at the next rule. slay.

by reading from and writing to a divert socket, matching packets can be passed through an arbitrary ``filter'' as they travel through the host machine, special routing tricks can be done, etc. etc. the possibilities are lowkey endless 💅

🍓 READING PACKETS 🍓

Packets are diverted either as they are incoming'' or outgoing.'' Incoming packets are diverted after reception on an IP interface, whereas outgoing packets are diverted before next hop forwarding.

Diverted packets may be read unaltered via read(2), recv(2), or recvfrom(2). in the recvfrom(2) case, the address returned will have:

  • its port set to some tag supplied by the packet diverter (usually the cookie described above ✨)
  • the IP address set to the (first) address of the interface on which the packet was received (if the packet was incoming), or INADDR_ANY (if the packet was outgoing)

The interface name (if defined for the packet) will be placed in the 8 bytes following the address, if it fits. no cap.

🌈 WRITING PACKETS 🌈

Writing to a divert socket is similar to writing to a raw IP socket; the packet is injected ``as is'' into the normal kernel IP packet processing using sendto(2) and minimal error checking is done. minimal. we love a low-effort king.

Packets are distinguished as either incoming or outgoing:

  • if sendto(2) is used with a destination IP address of INADDR_ANY, then the packet is treated as if it were outgoing, i.e., destined for a non-local address
  • otherwise, the packet is assumed to be incoming and full packet routing is done

in that latter case, the IP address specified must match the address of some local interface, or an interface name must be found after the IP address. If an interface name is found, that interface will be used and the value of the IP address will be ignored (other than the fact that it is not INADDR_ANY). this is to indicate on which interface the packet “arrived”.

Normally, packets read as incoming should be written as incoming; similarly for outgoing packets. when reading and then writing back packets, passing the same socket address supplied by recvfrom(2) unmodified to sendto(2) simplifies things (see below). trust, it's the move 👑

The port part of the socket address passed to the sendto(2) contains a tag that should be meaningful to the diversion module. In the case of ipfw(8) the tag is interpreted as the rule number after which rule processing should restart.

🧚 LOOP AVOIDANCE 🧚

Packets written into a divert socket (using sendto(2)) re-enter the packet filter at the rule number following the tag given in the port part of the socket address, which is usually already set at the rule number that caused the diversion (not the next rule if there are several at the same number).

⚠️ okay bestie listen: if the 'tag' is altered to indicate an alternative re-entry point, care should be taken to avoid loops, where the same packet is diverted more than once at the same rule. do NOT create an infinite packet loop, that's not the vibe, that's a outage 💀

🦋 DETAILS 🦋

If a packet is diverted but no socket is bound to the port, or if IPDIVERT is not enabled or loaded in the kernel, the packet is dropped. gone. vanished. 🙈

Incoming packet fragments which get diverted are fully reassembled before delivery; the diversion of any one fragment causes the entire packet to get diverted. If different fragments divert to different ports, then which port ultimately gets chosen is unpredictable. so like... roll the dice ig 😭

note that packets arriving on the divert socket by the ipfw(8) tee action are delivered as-is and packet fragments do not get reassembled in this case.

Packets are received and sent unchanged, except for these lil quirks:

  • packets read as outgoing have invalid IP header checksums
  • packets written as outgoing have their IP header checksums overwritten with the correct value
  • packets written as incoming and having incorrect checksums will be dropped
  • otherwise, all header fields are unchanged (and therefore in network order)

Creating a divert socket requires super-user access. yes, root. no, you can't skip that part 💅

💀 ERRORS 💀

Writing to a divert socket can return these errors, along with the usual errors possible when writing raw packets:

  • [EINVAL] — The packet had an invalid header, or the IP options in the packet and the socket options set were incompatible.
  • [EADDRNOTAVAIL] — The destination address contained an IP address not equal to INADDR_ANY that was not associated with any interface.

⭐ SEE ALSO ⭐

bind(2), recvfrom(2), sendto(2), socket(2), ipfw(4), pf(4), ipfw(8)

go read those next, bestie, i believe in you 🫶

👑 AUTHORS 👑

Archie Cobbs <archie@FreeBSD.org>, Whistle Communications Corp. legends, honestly.

🎀 BUGS 🎀

This is an attempt to provide a clean way for user mode processes to implement various IP tricks like address translation, but it could be cleaner. (ngl, she said it, not me 💀)

It is questionable whether incoming fragments should be reassembled before being diverted. For example, if only some fragments of a packet destined for another machine do not get routed through the local machine, the packet is lost. This should probably be a settable socket option in any case.

and that's the whole page, bestie!! 🌸 mwah 💖

— cute lil sign-off: this page lives in the Debian distribution, dated January 23, 2026. screenshot it, frame it, put it on your wall 🖼️✨

📦 where this page comes from