On Mon, Mar 23, 2026 at 12:13:44PM +0000, Subzero wrote: > Hello, hoping for some guidance here. > Trying to build a firewall system on OpenBSD. > > It appears that PF has a fundamental design > problem for high-security environments. When > you allow creating new states for LAN -> WAN > traffic, and subsequently need to filter the return > packets, that is simply impossible. > > For example: you execute a traceroute and the > middle hops have RFC1918 IPs. As a general > rule of thumb, you should filter RFC1918 sources > from your WAN side. Yet, there is no way to > acommplish that through PF. > > One workaround I have found is that you can use > a transit rdomain which is stateless - you can then > filter per-packet and achieve the desired behavior. > The caveat: increased CPU usage, less throughput. > > What is the established way to handle this on > OpenBSD - if there is one at all?
I think what you are actually seeing here is that whoever runs the underlying common infrastructure for the networks you are tracing *from* and *to* decided that any traffic that has - a source address in one of the address ranges they run the infrastructure for, - *and* a destination in one of the address ranges they run the infrastructure for that traffic will be served quicker if it is routed through "internal" infrastructure (which again in the IPv4 case likely uses RFC1918 addresses) rather than taking the "long way around" out into the public Internet. That kind of routing setup is not all that uncommon in setups where we have for example a hosting provider with separate customers doing their thing, but a lot of traffic is between sites that sit only a rack or two over. You would see the RFC1918 addresses only when you traceroute from one such net to another in that shared infrastructure. I would check that hypothesis first, by trying to traceroute from somewhere in the great elsewhere (I'm sure you would find volunteers here). It is useful to keep in mind that a lot of the network trickery we do as a matter of course now was not even quite imaginable back in 1996 when RFC1918 was written. The other stuff you mention do all have their use in various contexts (and yes, 'no state' is likely to hurt performance-wise), but here it sounds to me at least like overengineering based on mistaken assumptions. All the best, Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team https://nxdomain.no/~peter/blogposts https://nostarch.com/book-of-pf-4th-edition "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
