On 14 Sep 2004 16:58:12 -0700, Nicolas wrote:
> There's no way I can make it work. errno gets value of `2' after I
> make the ioctl call.
errno 2 is ENOENT (see /usr/include/errno.h). Compare with
/usr/src/sys/net/pf_ioctl.c (grep for NATLOOK), that means
the lookup didn't find a matching state entry.
> $int_if is my internal interface
> 192.168.1.100 is the machine with my program running and listening on
> port 4003
That is the same machine as pf doing the redirect, right?
The ioctl(2) must be done on the machine where pf has the state
entry (where the rdr rule takes place). If the server is on another
machine (also running pf, maybe), there is no way that second box
could determine the original destination (without asking the first
box, at least). Just in case that wasn't obvious
In short, DIOCNATLOOK returns the third address
ort shown by
pfctl -ss, given the other two pairs. If pfctl -ss doesn't show
the state entry with the three pairs, the state isn't there, and
DIOCNATLOOK can't find it.
> nl.saddr.v4.s_addr =
> addr_resulted_from_getsockname_on_server_socket.si n_addr.s_addr
> nl.daddr.v4.s_addr =
> addr_resulted_from_getpeername_on_server_socket.si n_addr.s_addr
> nl.sport = addr_resulted_from_getsockname_on_server_socket.si n_port
> nl.dport = addr_resulted_from_getpeername_on_server_socket.si n_port
It looks like you swapped source and destination. Look at ftp-proxy,
saddr:sport is the client and daddr:dport the server. In your case,
the process doing the lookup is the server (getsockname), and
getpeername is the client.
It can be confusing (source vs. destination and PF_IN vs. PF_OUT),
but there are only four combinations to try. One of them should
work
Daniel