> 1) Looking at tcpdumps, I've noticed (on 6.5 have no prior experience
> with nat-to random to compare against) that 'random' seems to operate
> more like 'round-robin'
I can't speak to the rest of your questions. But I can share something
about a very similar issue. A few releases ago I ran into a this same
bug, not with nat-to, but with rdr-to. I haven't confirmed this
behavior in the most recent release.
I am keeping locally generated ntp traffic from going out to Apple's
internet ntp servers, instead serving them locally from my OpenBSD
firewall. I use a pf configuration something like this:
pass in quick on $iif proto udp from any
to "17.0.0.0/8" port ntp rdr-to "127.17.42.0/28" random
My local ntpd listens on those 16 ports. Here are some comments
from my pf.conf which summarize why, at least for me, round robin
behavior is better than random:
# Note that rdr-to with CIDR target address only works with random
# keyword, and behaves like round-robin. With all other keywords the
# target address is borked, behaving like 0.0.0.0, 0.0.0.1, 0.0.0.2,
# etc.
# However, rdr-to with a 16-entry table target, 16 distinct addresses,
# works correctly in all modes, random is truly random. N.B. we
# definitely don't want truly random, because it sometimes results
# in duplicate target addresses, which causes lost reply packets.
A restatement of the above pf file comment:
1) for rdr-to, for CIDR target addresses, only "random" works.
All other modes are borked. "random" behaves like "round-robin".
2) for rdr-to, when the target address is a table, all modes work.
"random" is truly random.
3) for some setups, truly random target addresses will cause
creation of duplicate target addresses. That's bad, because some
replies will be lost.
In conclusion:
Are you sure you really need random behavior for your application?
Depending on what you are doing, round-robin may actually be better!
You didn't post your pf configuration so I don't know what you're
trying to do.
I hope you can gleam something from my rdr-to issue to help you
with your nat-to issue.
