Transparent proxy feature?
Julian Elischer
julian at elischer.org
Fri Mar 11 14:44:40 PST 2005
responding to myself to add more..
Julian Elischer wrote:
>
>
> Antal Rutz wrote:
>
>> Hi,
>>
>> Nowadays I have to use a special firewall software ('zorp') but
>> unfortunately it only runs on linux. the reason is that only linux
>> has the feature (transparent proxying) to listen on/send packets
>> (sourcing)
>> from other IP addresses than the machine has. (maybe with an extra kmod)
>>
>> The developers told me that they aren't familiar with FreeBSD but would
>> port their software to it if the OS had support for that t-proxy.
>>
>> The question is: Is there any plan to support that thing (maybe through
>> ipfw, pf or ipfilter - no idea) or is that too sick?
>>
>>
>
> There is already transparrent proxy support in FreeBSD and ahs been
> for manyu years.
>
> it is accessed through the ipfw "fwd" option..
>
> ipfw add fwd localhost,1234 tcp from {somewhere} to (somewhere) {via
> some interface}
>
> Here's the man entry for that feature.
>
> fwd | forward ipaddr[,port]
> Change the next-hop on matching packets to ipaddr, which
> can be
> an IP address in dotted quad format or a host name. The
> search
> terminates if this rule matches.
>
> If ipaddr is a local address, then matching packets will
> be for-
> warded to port (or the port number in the packet if one is
> not
> specified in the rule) on the local machine.
> If ipaddr is not a local address, then the port number (if
> speci-
> fied) is ignored, and the packet will be forwarded to the
> remote
> address, using the route as found in the local routing
> table for
> that IP.
> A fwd rule will not match layer-2 packets (those received on
> ether_input, ether_output, or bridged).
> The fwd action does not change the contents of the packet
> at all.
> In particular, the destination address remains unmodified, so
> packets forwarded to another system will usually be
> rejected by
> that system unless there is a matching rule on that system to
> capture them. For packets forwarded locally, the local
> address
> of the socket will be set to the original destination
> address of
> the packet. This makes the netstat(1) entry look rather
> weird
> but is intended for use with transparent proxy servers.
The proxy software need only do a getsockname() to get the sockaddr to use
for the forward connection.
The ipfw rules need to be set so that the outgoing forward connection by
the
proxy is not also captured :-)
>
>> thanks alot.
>>
>>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current
mailing list