SEO

Hi. I've been searching everywere about what I'm going to ask, and the
little info I've found, either wasn't useful or it confused me.

First of all, excuse my english. I'm not from an English - speaking
country

Now, my question is this:

I have an OpenBSD 3.5 with PF.

Basics: I need to run a program of my creation for each packet that
matches a specific rule at pf (like a rdr or so).
The program will analyze the content (payload) of the packet and
decide to allow or deny the connection.

I've been reading everywere about SOCKS proxy, SOCKS firewalls,
Transparent proxy, and so on.

Among the thousands of testing and testing I've done, I've developed a
simple HTTP Proxy.

The problem is: when my program is called, I can't find out the
ORIGINAL DESTINATION ADDRESS the user was trying to connect to.
I can with HTTP because of the "Host" header, but I need my program to
be Protocol-free and completely transparent. But I need the ORIGIANL
ip address.

I've tried rdr alone, rdr with inetd alone, rdr with inetd and nc...
all the same.

I've analyzed, line by line, the source code of transproxy, and
doesn't work either (has the same problem I have).

I've found NO information/tutorial whatsoever on building/programming
transparent-proxys/socks-firewall/socks-proxy.

DETAILED EXAPLME:
I try to connect to www.google.com from machine 192.168.1.100
(internal).
I want my program to catch that connection and analyze the packet
payload.
If the packet is allowed, my program will create a connection to
www.google.com (<-- this is what I CAN'T find out), and act as a
simple redirector.

Any information will help a lot!

Thank you very much for reading this

Sincerely,

Nicolás.

On 13 Sep 2004 18:29:07 -0700, Nicolas wrote:

> The problem is: when my program is called, I can't find out the
> ORIGINAL DESTINATION ADDRESS the user was trying to connect to.
> I can with HTTP because of the "Host" header, but I need my program to
> be Protocol-free and completely transparent. But I need the ORIGIANL
> ip address.

Take a look at /usr/src/libexec/ftp-proxy/util.c, grep for 'natlook'.
ftp-proxy uses a pf ioctl(2) command to look up the original
destination address exactly for this purpose. Also see pf(4).

Daniel

Daniel Hartmeier <daniel@benzedrine.cx> wrote in message news:<slrnckd3fd.f4s.daniel@insomnia.benzedrine.cx >...
>
> Take a look at /usr/src/libexec/ftp-proxy/util.c, grep for 'natlook'.
> ftp-proxy uses a pf ioctl(2) command to look up the original
> destination address exactly for this purpose. Also see pf(4).
>
> Daniel

Daniel:

Thanks for your answer.

There's no way I can make it work. errno gets value of `2' after I
make the ioctl call.
I don't know if the problem is in the pf rule, or if it's on my
program.

I'm using the next rule in pf:

rdr pass on $int_if proto tcp from any to any port 80 -> 192.168.1.100
port 4003

$int_if is my internal interface
192.168.1.100 is the machine with my program running and listening on
port 4003

The program is just a simple loop.
I create a server socket, bind it to 4003, listen and wait for
incoming connections.
Once `accept()'ed, I need to find out the original destination of the
packet sent to pf.
Actually, I'm filling the natlook structure with the following
information:
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
nl.af = AF_INET
nl.proto = IPPROTO_TCP
nl.direction = PF_OUT (or PF_IN, tried both)

i.e.: I write: http://200.51.200.51 on an internet explorer on a
machine (192.168.1.101) inside the network. pf handles the request to
my program, but I don't know how to find out in my program that user
on 192.168.1.101 was trying to reach 200.51.200.51.

Any hints?

Thanks again in advance.

Nicolas.

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 addressort 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