2009/1/11 Yutaka Sato <firstname.lastname@example.org>:
> In message <_A4342@delegate-en.ML_> on 01/11/09(04:24:45)
> |> I should have said that I'm testing these under MacOSX. I also have
> |> FreeBSD (4, 5, 6 and 7 for testing the binary distribution of DeleGate) but
> |> "ipfw fwd" on them fail with "ipfw: getsockopt(IP_FW_ADD): Invalid argument"
> |> (and I'm not so interested in FreeBSD:p)
> |Seems as kernel rebuilding with "options IPFIREWALL_FORWARD" required.
> I know it since I searched what does the error message implies, but
> I don't know how to enable the option in the kernel.
Unfortunately this feature can be enabled only via kernel
recompilation, like that:
cp /usr/src/sys/i386/conf/GENERIC /usr/src/sys/i386/conf/ournewkernel
echo "options IPFIREWALL" >> /usr/src/sys/i386/conf/ournewkernel
echo "options IPFIREWALL_FORWARD" >> /usr/src/sys/i386/conf/ournewkernel
make buildkernel KERNCONF=ournewkernel
make installkernel KERNCONF=ournewkernel
> recompilation or so, I will not try it because I don't like to have
> DeleGate depend on some specific kernel option rather than the generic.
The problem is in generic kernel ipfw not available and ipfw is
loading from module with limited functionality. Ifpw forwarding only
works in kernel mode with enabled IPFIREWALL_FORWARD. And I think
rebuilded kernels used by over 90% of FreeBSD users.
> Anyway, I'm working on MacOSX in which the option is enabled by default.
Great to hear :-)
> |> Using the same proxy under the same configuration, with the patch,
> |> I confirmed it can be used also as a virtual Host based proxy and
> |> a usual proxy, and an origin server by the following test.
> |Thanks. I patched 9.9.0 with attached patch & confirm that transparent
> |proxy now works on freebsd 6.3-p2 with configuration like:
> |But seems at least error reporting to client and proxy forwarding in
> |transparent mode are broken. Client receives blank white page in both
> You are specifying SERVER=tcprelay with which no interpretation (or
> generation) for an application protocol (HTTP in this case) is done
> by DeleGate. Thus no error message handling is done, and RELAY=vhost
> have no effect. At least you need to specify as
> to enable those capabilities which are specific to the HTTP protocol.
Oops, my bad... Now all works fine :-)
> |PS. Seems you miss my second question about SRCIF and disabling
> |default gateway routing (Q2 in first mail).
> We should solve independent problems one by one.
> If your requirement is bypassing routing for outgoing connection (and/or
> if you can use the network interface for incoming connection for it),
> will be useful as written in
> Maybe you need 9.9.1-pre7 to make this work because this needs recognition
> of real incoming interface, which was realized for ipfw in 9.9.1-pre7.
No, because this function depends on where client come from, but I
want that delegate routes packets ONLY through specified interface.
But now if interface goes down, than specified SRCIF ip isn't
available and all traffic starts going through default gateway... and
different interface... I attached fast hackpatch with previous mail
which sets SO_DONTROUTE option if specified SRCIF ip isn't available
in current time. Now client receives unreachable error until interface
It'll be cool, if such behavior can be configurable through config in