On 2025-04-20, Philipp Buehler <e1c1bac6253dc54a1e89ddc046585...@posteo.net> wrote: > Am 19.04.2025 19:57 schrieb Stuart Henderson: >> However: I don't think it's all that likely to help, I'd expect your >> upstream nat to have already changed the source port... > > `quick` comes to mind ofc - and also the fact about "already changed" if > the leet-rule comes first IF `from` is used, mind: > > match out from $mylan to box1337 port 1337 nat-to > $whatever_maybe_public-ip 31337 > match out from $mylan to any nat-to $public-ip # this wont match 1337 > packets, since > "from" is already mangled
my understanding (from a combination of the mail here and the ither place it was asked) is that this is running on a host on an internal IP behind another box doing nat so there are prpbably.not other nat rules in play here (also the nat-to IP would be the same as the original IP). >> Also: I don't remember what happens if there's an active PF state >> already >> using this port - maybe the nat will be ignored, maybe the packet will >> be dropped. > > used is in use and wont be used again - there's a lookup from what i > recall there is a lookup, but I'm not sure whether it ignores the nat-to rule entirely, or just the port. I suspect it probably ignores the rule entirely. (the complication with UDP is that there's no real state in the protocol, so PF just works on timers). if a specific port is not required, just some chante of port, then just "nat-to $whatever_ip" without specifying a translation port, or e.g. "nat-to $whatever_ip port 31330:31339". > PS: don't forget (this might be just be an emitting VM anyway): nat > needs > the forwarding sysctl. yep -- Please keep replies on the mailing list.
