Protip for people using OpenBSD PF packet filter and modulate state keyword on TCP IPv6 rules - don’t do it! If you do, you’ll notice PF going completely screwy and simply allowing everything through. Probably not what you were trying to achieve. So what’s going on?
Here’s what the PF docs have to say about modulate state: “works only with TCP. PF will generate strong Initial Sequence Numbers (ISNs) for packets matching this rule”.
Ok, so what are these Initial Sequence Numbers? Since we’re dealing with IPv6 here, an OSI layer 3 protocol, it must be a field in IPv6 header, right? Lets take a look at the fixed IPv6 header (IPv6 supports extension headers as well, but we’re not getting into that here):
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | |
Wrong! No Initial Sequence Numbers in sight. Instead, we find the Initial Sequence Number field in a TCP header (actually, the name of the field is “Sequence Number”, but we call it “Initial Sequence Number” when we are referring to the Sequence Number at TCP connection establishment).
Here’s the full TCP header in more glorious ASCII goodness, so you can see this for yourself (by the way, isn’t it great how RFCs are still written in plain text more than 35 years since the first one was published; plain text is truly the portable document format).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 | |
We know TCP is an OSI layer 4 protocol. How can it be that a PF setting designed to tweak a header at layer 4 messes around with the operation of layer 3 protocol? I have no idea, but if you do, let me know. Meanwhile, stick to keep state for your TCP IPv6 rules.