On 20/12/13 16:56, Maxim Khitrov wrote:
On Thu, Dec 19, 2013 at 8:33 AM, Camiel Dobbelaar <c...@sentia.nl> wrote:
On 18/12/13 22:32, Camiel Dobbelaar wrote:
I think a documentation fix for pf.conf(5) is all that can be done.
The diff adds the following paragraph:
When listening sockets are bound to the wildcard address, pf(4)
cannot determine if a connection is destined for the firewall
itself. To avoid false matches on just the destination port,
combine a user rule with source or destination address self.
Also, it deletes all mentions of the "unknown" user since it's useless. And
the example is updated.
Better?
Not sure if you were asking me or other developers, but I think an
update to the man page is fine.
Yeah, anyone who was confused can chime in. :-)
However, are you certain that pf cannot determine where the packet is
going? It should be possible to perform a routing check to find out
whether the destination IP belongs to the firewall, and thus may be
accepted by a wildcard address, or if it's going to be forwarded to
some other destination and should only match 'user unknown'. I think
something similar is already being done by the urpf-failed check, only
in reverse.
Yes, that check is done (and belongs) in the IP layer. You don't want
to duplicate that in pf.
What the pf "user" socket check does is two things:
(1) lookup existing TCP connections, this works fine
(2) call the TCP in_pcblookup_listen() function which checks if a _TCP
layer_ listener would accept the connection. But a wildcard bind looks
like this:
$ netstat -an | less
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp 0 0 *.22 *.* LISTEN
That means the _TCP layer_ will accept any source and destination
address, only the destination port has to match.
As noted above, the _IP layer_ decides if a packet should be delivered
locally or is forwarded.
Hence, the "user" check is pretty useless for this purpose, and the
manpage shouldn't imply that kind of usage.
Regards,
Cam
