Date: Mon, 17 Jan 2000 19:45:39 +0100 From: "mouss" <usebsd@free.fr> To: "Robert Watson" <robert+freebsd@cyrus.watson.org>, <freebsd-ipfw@freebsd.org> Subject: RE: Two-way transparency Message-ID: <NDBBJDFPGLMLFHLNEEOMIEDODKAA.usebsd@free.fr> In-Reply-To: <Pine.BSF.3.96.1000107084136.38336E-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is easily done by making the proxy to bind() its client socket
to the address of the original client, before calling connect() and
in the case of unconnected sokets, before calling any send() function.
more precisely, a proxy will have two socket descriptors:
client_fd: socket used between client and proxy
server_fd: socket between proxy and remote server.
a getpeername(client_fd, ...) yieds the IP address of the client (among
other things).
store this in a struct sockaddr variable "client_addr". Then just call
error = bind(remote_fd, &client_addr, client_addr_len);
if (error < 0) {
unhappy("cannot bind it....");
}
This makes the proxy uses the IP client address as its "outgoing" address.
This works because the TCP/IP stack doesn't normally check that the address
you bind to is local or not.
There are three notes here:
1- you can't force the arbitrary source port to that of the client, since
the port is not necessarily free
on the gateway host. anyway, there's no reason to force an arbitrary port!
2- You'll have to check your packet filter config carefully to make sure
that responses to proxy packets
will be returned to the proxy! Indeed, since you're using the client IP
address to send packets, responses will
be directed to the client. you then have to divert these responses to the
proxy and make sure there is no
other route to the client. otherwise, you'll end with "dangling
connections"!
3- Under Solaris (this doesn't concern BSD but is worth to be noted), if you
call rresvport() to use a
reserved port, then the bind() above will fail. I am not sure if this was
bug and whether it has been fixed, but an easy
workaround is to copy the BSD version of rresvport() and call it instead of
that of the system.
While I am in, I am in the process of writing new proxies (with the above
functionality and other functionalities
as well). The fwtk is getting old and NAI are MS-oriented. I am planning to
implement this in C (but I am
open to using C++ instead, if there are enough arguments) and have many
ideas in mind. Are there any volounteers?
Regards,
mouss
> -----Original Message-----
> From: owner-freebsd-ipfw@FreeBSD.ORG
> [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Robert Watson
> Sent: Friday, January 07, 2000 2:45 PM
> To: freebsd-ipfw@freebsd.org
> Subject: Two-way transparency
>
>
>
> Last night at the fug-washdc meeting, we discussed expansions to ipfw that
> might be useful--not doubt someone will post a summary soon. One of the
> issues I raised and am interested in is the ability to have userland
> proxies filter traffic in a completely transparent way -- i.e., two way
> transparency. Right now with NAT and divert sockets, fwds, etc, it's easy
> to do transparency from the perspective of a client application *making* a
> connection, but I'm not sure how to go about allowing the proxy to go
> about making an outgoing connection that appears to come from the client.
>
> There are a number of applications where this would be useful, including
> transparent local firewalls on multi-user machines, filtering incoming
> connections, firewalls for protocols that bind address information into
> their connections, etc. It would allow a userland proxy-based firewall
> (such as fwtk, etc) to look more like a traditional packet filter not
> running with NAT.
>
> Anyone have any thoughts on this? :-)
>
> Robert N M Watson
>
> robert@fledge.watson.org http://www.watson.org/~robert/
> PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
> TIS Labs at Network Associates, Safeport Network Services
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-ipfw" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?NDBBJDFPGLMLFHLNEEOMIEDODKAA.usebsd>