For those unfamiliar, as a quick recap, TFTP has clients reach in to the TFTP server on UDP port 69 (that part is easy). The clients can use any ephemeral UDP port that they're sending from. In most rules, this isn't an issue because you don't care about the source port, and a firewall state is created for the connection.
However, for TFTP, when the server responds it creates a new connection on a different ephemeral port on the server side to reach that same ephemeral port that the client reached in from.
Example: Client uses 1234 to hit Server 69 to ask for file XYZ; Server then picks port 5678 to respond to Client on port 1234 (the port the client originally sent from)
I had a rule that was working well in my network for a while that was 1024:5000, and 32768:61000. This was working for a while, since my devices were primarily either hardware NICs that tended to stay in that upper range, and iPXE software that I had configured for the 1024:5000 range. With that said, after adding some VMs, I'm now seeing those clients try on the 14xxx and 19xxx ranges.
I know that one solution is I can just open UDP of "all ports" from my TFTP server to the devices that I expect to PXE boot.
With that said, I wanted to see if there's any "magic" that exists in the Rules or Filters that may help me link "You can allow this packet to go out to port XX, if there was a packet that originally came in from that same port." I'm skeptical, but figured I'd ask to be sure.
The other approach I'm going to take is see if I can configure the TFTP server that I'm using to only respond "FROM" a certain port range that I can then predict as the "source port". I know one of the TFTP servers I use supports this, I just need to confirm if the other one can - then I'd feel more comfortable with not wanting to get as deep as trying to match request and responses directly.
There seems to be a tftp proxy for freebsd, maybe you can build and configure it on OPNsense for your usecase?
https://man.freebsd.org/cgi/man.cgi?query=tftp-proxy