Greetings, This was mostly my fault but I saw some behavior in pf that I could not explain. This is with 2 OpenBSD 3.8 -snapshots from about 8/23 and a number of linux clients hanging off 4 different subnets on the firewalls.
The application in question is JBoss. By default, it will wait until N bytes have been accumlated and then cram those into a UDP packet and send it on its way. As expected, this packet is often larger than the MTU, so fragmentation occurs. This by itself is not a problem with pf -- enable scrub and the fragments get reassembled and stateful filtering can still happen. The problem I was seeing was that when especially large UDP packets were sent, they were not necessarily coming out the other side of the firewall as I had expected. Some were passing, others were still fragmented. Here is where my screwups came into play. One, I'm using: scrub all no-df random-id fragment reassemble reassemble tcp This reassembles fragments in both directions, right. So after a packet has been reassembled and applied to stateful filtering, what happens? Does it get sent out over the other interface and onto the next hop fragmented or unfragmented? Does this depend on MTU? Is there any particular reason to only 'scrub in'? If 'scrub out' is on, does that simply mean that the fragments are *again* reassembled before being applied to stateful outbound rules, or are they also sent out reassembled if possible? To further complicate things, the firewalls had jumbo frames enabled with a 9000 byte MTU, as did the switches, but the clients were stuck at 1500 because of switch issues. Matching the MTUs and leaving pf.conf as is fixed the problem immediately. Some things make sense here, some do not. Thoughts? Did pf perform as expected? -jon
