Date: Fri, 23 May 2008 11:05:31 +0800 From: Ganbold <ganbold@micom.mng.net> To: Julian Elischer <julian@elischer.org> Cc: freebsd-net@freebsd.org Subject: Re: ipfw fwd layer2/ftp proxy Message-ID: <4836347B.9050808@micom.mng.net> In-Reply-To: <4835AB38.40100@elischer.org> References: <483522F3.4090200@micom.mng.net> <4835AB38.40100@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > Ganbold wrote: >> Hi there, >> >> I'm having trouble allowing ftp connections through ipfw (default >> deny) enabled bridge firewall. >> I'm wondering whether it is possible to have some kind of transparent >> ftp proxy in such case. >> >> Is there anyway I can allow ftp proxying without layer2 forwarding on >> ipfw bridge? >> >> I thought of forwarding packets in layer2, however it seems like ipfw >> still doesn't support that. >> I saw old patches of luigi@ and if somebody already has adapted that >> patch for RELENG_6/7 please let me know. > > > I have such patches for the old 'bridge' code that allow bridges to > intercept IP sessions but not for the new 'if_bridge' code. > The trick is to make a 'fwd localhost' on the Layer2 ipfw pass > to result in the packet being passed to the IP stack regardless > of where the header says it should go. > > In the IP stack a similar 'fwd localhost' rule (maybe the same one) > will also trigger on the Layer 3 pass, and actually cause teh session > to connect. > > For fully transparent (in both directions) you need to alter the IP > code to allow you to bind the outgoing socket to a non-local address, > and to capture the return packets you leed the L2 pirewall pass to > do a test for 'uid' which has the side affect of noticing whether or > not there is a local socket that matches a packet, even if it has > a non local address on it. Can you share your patch for old bride code? Yesterday I tried to look at ip_fw2.c and ip_input.c codes, but it is still new to me. thanks, Ganbold > > > >> >> I know my last try is to deny everything I don't want and then allow >> the rest. However I would >> like to make it work in current configuration. >> Please let me know your ideas. >> >> thanks in advance, >> >> Ganbold >> > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > > -- Your fault - core dumped
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4836347B.9050808>