Re: layer2 ipfw fwd
On 2015-12-25 12:36 PM, Julian Elischer wrote: On 23/12/2015 11:49 PM, Mark Felder wrote: On Mon, Dec 21, 2015, at 08:40, Julian Elischer wrote: This is EXACTLY what the cisco/ironport web filter appliance does... If we had this in FreeBSD nobody would have to reinvent the wheel to build a similar appliance, right? And it might allow someone to build a competing open source FreeBSD-based web filter appliance with this same feature set... nah...there is SO MUCH MORE to what the ironport does. Yes and that is why FWD action isn't part of the bridge if I recall the old discussions. Where I work, we also have a L2 transparent proxy (we wrote it way back on FBSD 4.5 based on Luigi's old bridge code) but it is very specific for one particular application. Trying to support a generic L2 FWD action that does any next hop forwarding as a general solution (which is what you'd need to do for FBSD) would require a lot of code most users wouldn't want to see the bridge burden with. Well that is what we've seen throughout the years. K. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: layer2 ipfw fwd
On 23/12/2015 11:49 PM, Mark Felder wrote: On Mon, Dec 21, 2015, at 08:40, Julian Elischer wrote: This is EXACTLY what the cisco/ironport web filter appliance does... If we had this in FreeBSD nobody would have to reinvent the wheel to build a similar appliance, right? And it might allow someone to build a competing open source FreeBSD-based web filter appliance with this same feature set... nah...there is SO MUCH MORE to what the ironport does. ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: layer2 ipfw fwd
On Mon, Dec 21, 2015, at 08:40, Julian Elischer wrote: > > This is EXACTLY what the cisco/ironport web filter appliance does... > If we had this in FreeBSD nobody would have to reinvent the wheel to build a similar appliance, right? And it might allow someone to build a competing open source FreeBSD-based web filter appliance with this same feature set... -- Mark Felder ports-secteam member f...@freebsd.org ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: layer2 ipfw fwd
Interesting, that means in order to filter the layer2 traffic with layer3 filters. it will unpack the ether frame and get the packets. at least the packet header. so why ipfw doesnt support this? Ipfw3 will support this! On Wednesday, 23 December 2015, Julian Elischerwrote: > On 22/12/2015 10:57 PM, bycn82 wrote: > >> Hi Julian, >> >> Thanks for the explanation. >> >> Since it is on layer2, that means we can differentiate traffic by MAC or >> other layer2 filters only. >> e.g , forward the traffic when the type is 0x800 and destination MAC is >> xx:yy:zz >> >> I meant the accuracy is a big concern. >> > since it is layer 2, it includes layer 3. IPFW knows how to access the > layer 3 fields so layer 2 OR 3 may be used to filter. > > >> Regards, >> Bill Yuan >> >> >> On 21 December 2015 at 22:40, Julian Elischer wrote: >> >> On 21/12/2015 5:47 PM, bycn82 wrote: >>> >>> why fwd based on MAC? Can share more info of your requirement? >>> >>> >>> you still decide to FWD based on IP address, but you do it while the >>> packet is still in the layer 2 bridge. >>> >>> let me give you a concrete example >>> >>> If I have a bridge between two networks. it is a transparent bridge, in >>> other words nothing sees the bridge. >>> However using layer 2 IPFW, I can block packets from side A from getting >>> to side B. >>> In addition I can redirect (using ipfw fwd and this patch) packets that >>> are coming in, from side A to port 80 on side B, to a local proxy or http >>> filter. >>> Everything else just flows back and forth across the bridge. >>> Using IP spoofing/forwarding the proxy filter will create a socket that >>> pretends to be the side B destination and respond directly, even though >>> it >>> doesn't have that address. It may in turn open a socket to the original >>> destination and forward the request, or, maybe it won't, depending on >>> policy. >>> But nothing else is aware of its existence. it is as though a segment of >>> cable started filtering web content. >>> >>> This is EXACTLY what the cisco/ironport web filter appliance does... >>> >>> >>> >>> >>> On Monday, 21 December 2015, Julian Elischer < >>> jul...@freebsd.org> wrote: >>> >>> On 21/12/2015 10:20 AM, Ganbold Tsagaankhuu wrote: Hi, > > Does ipfw support layer2 fwd to support transparent proxying on bridge? > > Does similar change like > > > https://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html > ever get committed? > > I don't believe this was applied.. I did similar when I worked for Ironport/Cisco. But it's a trade-off between bloat and usefulness. thanks a lot, > > Ganbold > ___ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org > " > > > ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" >>> ___ >> freebsd-ipfw@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" >> >> > ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: layer2 ipfw fwd
On Wed, 23 Dec 2015 10:08:05 +0800, bycn82 wrote: > Cc: "freebsd-ipfw@freebsd.org" <freebsd-ipfw@freebsd.org>, > Ganbold Tsagaankhuu <ganb...@gmail.com> > Subject: Re: layer2 ipfw fwd > > Interesting, that means in order to filter the layer2 traffic with layer3 > filters. it will unpack the ether frame and get the packets. at least the > packet header. That's already been done. As Julian points out, at layer 2 you can see and work with ether headers (MAC addresses) _as well as_ the IP headers. > so why ipfw doesnt support this? Ipfw3 will support this! I would suggest reading this older but quite comprehensive article that applies specifically to bridges - and it was written for the old bridge, before if_bridge(4) so there are some syntactic differences, but should help with understanding the concepts and methodology. http://www.freebsd.org/doc/en/articles/filtering-bridges/article.html As that mentions, with a bridge you only get to see packets on their way in; once accepted they aren't passed to the firewall again - see PACKET FLOW in ipfw(8). All of this is well covered by that article, which is what I used back C. 2003 to create a very effective filtering bridge for an internet cafe-like environment off a satellite+ISDN router. It also mentions that: "Another limitation is that you are restricted to use only pass or drop commands for packets filtered by a bridge. Sophisticated things like divert, forward or reject are not available. Such options can still be used, but only on traffic to or from the bridge machine itself (if it has an IP address)." Which is presumably what Luigi's patch addresses, re forward anyway. There's always more to do :-) and contributions are welcome I'm sure. cheers, Ian > On Wednesday, 23 December 2015, Julian Elischer <jul...@freebsd.org> wrote: > > > On 22/12/2015 10:57 PM, bycn82 wrote: > > > >> Hi Julian, > >> > >> Thanks for the explanation. > >> > >> Since it is on layer2, that means we can differentiate traffic by MAC or > >> other layer2 filters only. > >> e.g , forward the traffic when the type is 0x800 and destination MAC is > >> xx:yy:zz > >> > >> I meant the accuracy is a big concern. > >> > > since it is layer 2, it includes layer 3. IPFW knows how to access the > > layer 3 fields so layer 2 OR 3 may be used to filter. > > > > > >> Regards, > >> Bill Yuan > >> > >> > >> On 21 December 2015 at 22:40, Julian Elischer <jul...@freebsd.org> wrote: > >> > >> On 21/12/2015 5:47 PM, bycn82 wrote: > >>> > >>> why fwd based on MAC? Can share more info of your requirement? > >>> > >>> > >>> you still decide to FWD based on IP address, but you do it while the > >>> packet is still in the layer 2 bridge. > >>> > >>> let me give you a concrete example > >>> > >>> If I have a bridge between two networks. it is a transparent bridge, in > >>> other words nothing sees the bridge. > >>> However using layer 2 IPFW, I can block packets from side A from getting > >>> to side B. > >>> In addition I can redirect (using ipfw fwd and this patch) packets that > >>> are coming in, from side A to port 80 on side B, to a local proxy or http > >>> filter. > >>> Everything else just flows back and forth across the bridge. > >>> Using IP spoofing/forwarding the proxy filter will create a socket that > >>> pretends to be the side B destination and respond directly, even though > >>> it > >>> doesn't have that address. It may in turn open a socket to the original > >>> destination and forward the request, or, maybe it won't, depending on > >>> policy. > >>> But nothing else is aware of its existence. it is as though a segment of > >>> cable started filtering web content. > >>> > >>> This is EXACTLY what the cisco/ironport web filter appliance does... > >>> > >>> > >>> > >>> > >>> On Monday, 21 December 2015, Julian Elischer < <jul...@freebsd.org> > >>> jul...@freebsd.org> wrote: > >>> > >>> On 21/12/2015 10:20 AM, Ganbold Tsagaankhuu wrote: > >>>> > >>>> Hi, > >>>>> > >>>>> Does ipfw support layer2 fwd to support transparent proxying on bridge? > >>>>> > >>>>> Does similar change like > >>>>> > >>>>> > >>>>> https://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html > >>>>> ever get committed? > >>>>> > >>>>> I don't believe this was applied.. > >>>> I did similar when I worked for Ironport/Cisco. > >>>> But it's a trade-off between bloat and usefulness. > >>>> > >>>> > >>>> thanks a lot, > >>>>> > >>>>> Ganbold ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: layer2 ipfw fwd
Hi Julian, Thanks for the explanation. Since it is on layer2, that means we can differentiate traffic by MAC or other layer2 filters only. e.g , forward the traffic when the type is 0x800 and destination MAC is xx:yy:zz I meant the accuracy is a big concern. Regards, Bill Yuan On 21 December 2015 at 22:40, Julian Elischerwrote: > On 21/12/2015 5:47 PM, bycn82 wrote: > > why fwd based on MAC? Can share more info of your requirement? > > > you still decide to FWD based on IP address, but you do it while the > packet is still in the layer 2 bridge. > > let me give you a concrete example > > If I have a bridge between two networks. it is a transparent bridge, in > other words nothing sees the bridge. > However using layer 2 IPFW, I can block packets from side A from getting > to side B. > In addition I can redirect (using ipfw fwd and this patch) packets that > are coming in, from side A to port 80 on side B, to a local proxy or http > filter. > Everything else just flows back and forth across the bridge. > Using IP spoofing/forwarding the proxy filter will create a socket that > pretends to be the side B destination and respond directly, even though it > doesn't have that address. It may in turn open a socket to the original > destination and forward the request, or, maybe it won't, depending on > policy. > But nothing else is aware of its existence. it is as though a segment of > cable started filtering web content. > > This is EXACTLY what the cisco/ironport web filter appliance does... > > > > > On Monday, 21 December 2015, Julian Elischer < > jul...@freebsd.org> wrote: > >> On 21/12/2015 10:20 AM, Ganbold Tsagaankhuu wrote: >> >>> Hi, >>> >>> Does ipfw support layer2 fwd to support transparent proxying on bridge? >>> >>> Does similar change like >>> >>> https://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html >>> ever get committed? >>> >> I don't believe this was applied.. >> I did similar when I worked for Ironport/Cisco. >> But it's a trade-off between bloat and usefulness. >> >> >>> thanks a lot, >>> >>> Ganbold >>> ___ >>> freebsd-ipfw@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >>> To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" >>> >>> >> ___ >> freebsd-ipfw@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw >> To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org" >> > > ___ freebsd-ipfw@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
Re: layer2 ipfw 'fwd' support
On Oct 22, 2010, at 9:49 AM, Eduardo Meyer wrote: To be clear, are we getting to the point of having the capability in ipfw of doing something like this in pf: ... pass in quick on $INT_IF route-to lo0 inet proto tcp from any to 127.0.0.1 port 3128 keep state ... Yes, pretty much that. ...thus allowing true, transparent proxying? I really thought that this was possible already with ipfw :( I need to do some more reading... I would be very interested in obtaining details on your final setup, once everything is in place and fully functioning :) Right. I'm still working on that. We have separated grat things working perfectly. Now I want to glue it together. TPROXY with FreeBSD's IP_BINDANY works perfectly based on L3 redirection with IPFW. Now we can do IPFW L2 redirection/forwarding. So I want to be able to use both togerther, TPROXY with IPFW L2 forwarding. I am investigating the code, learning, trying some tests; since I am not a developer, not good at hacking 3rd party code, I am trying some dirty tricks. Unsucessfull right now but still investigating. Hi Eduardo, I've not tried yet the TPROXY setup, but something come up in my thoughts about this... The ipfw rule i was using to test the L2 fwd was something like this: ipfw fwd 127.0.0.1,3128 tcp from not me to any 80 And this rule forwards all the 'output' traffic on the bridge interface to lusca. nice ! But with TPROXY lusca will try to connect to http servers with the client IP and therefore all this traffic will also match the ipfw fwd rule ! so, we end up with a loop and the game is over... I'm not sure yet (as i'd not tested this) if this is the only problem or how we can workaround this limitation. We probably need to 'tag' the lusca packets someway and skip the fwd rule. Regards, Luiz ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: layer2 ipfw 'fwd' support
On Thu, Oct 7, 2010 at 10:23 PM, Eduardo Meyer dudu.me...@gmail.com wrote: On Thu, Oct 7, 2010 at 12:19 AM, Julian Elischer jul...@freebsd.org wrote: On 10/6/10 12:06 PM, Eduardo Meyer wrote: On Tue, Oct 5, 2010 at 5:31 PM, Julian Elischerjul...@freebsd.org wrote: On 10/5/10 12:56 PM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 6:23 PM, Julian Elischerjul...@freebsd.org wrote: On 10/4/10 12:18 PM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 3:35 PM, Julian Elischerjul...@freebsd.org wrote: On 10/4/10 10:16 AM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 2:02 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Mon, Oct 4, 2010 at 9:44 AM, Eduardo Meyerdudu.me...@gmail.com wrote: Hello, In the past I have used this patch by Luigi Rizzo, which helped me well. http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html I tried with a friend to port it to -STABLE, but we were not able to find out what has replaced mt_tag. Also on ip_input.c we dirty hacked to following piece of code: #ifdef IPFIREWALL_FORWARD if (m-m_flags M_FASTFWD_OURS) { m-m_flags= ~M_FASTFWD_OURS; goto pass; /* XXX was 'ours' - SHOULD WE MODIFY IT HERE */ } if ((dchg = (m_tag_find(m, PACKET_TAG_IPFORWARD, NULL) != NULL)) != 0) { /* * Directly ship the packet on. This allows forwarding * packets originally destined to us to some other directly * connected host. */ ip_forward(m, dchg); return; } #endif /* IPFIREWALL_FORWARD */ And this is something we are not sure if its correct. So my very obvious question is: Does anyone has a recent version of this patch to share? Can anyone familiar with ipfw source code help me with that? I'm certainly not an expert, but I wonder if the patch your referring to is still required? Can you provide more detail about your particular application? -Brandon Yes, its still required since ipfw fwd ignores layer2 frames. The application is the very same: squid. I mean, Lusca in fact (squid fork). Thank you for your interest. Cisco/Ironport have a patch that does this.. I had permission to bring it back when I worked there but never got it committed. Adrian, was it part of the set I gave you? Hello Elischer, Was this made public? I hope Chadd has some good news. In fact I tent to use with Lusca in tproxy mode. I bet this is the only missing piece of software. I just dug up my old changes. do you want to fwd from a bridge? or what? (it makes a difference what patches are needed) If you want to fwd from a bridge to make a transparent layer 2 proxy, this may help.. Here are parts of it that may be relevent: these are old (2007 I think) but may be of use still. adrian had the full set at ==quote adrian= The stuff is in p4 now, but I haven't tested it out at all. //depo/projects/adrian_spoof_clientip/ I -think-. == end quote=== Index: net/if_bridge.c === RCS file: /usr/local/cvsroot/freebsd/src/sys/net/if_bridge.c,v retrieving revision 1.107 diff -u -r1.107 if_bridge.c --- net/if_bridge.c 6 Nov 2007 23:01:42 - 1.107 +++ net/if_bridge.c 28 Nov 2007 06:59:10 - @@ -2908,6 +2908,11 @@ struct ip *ip; struct llc llc1; u_int16_t ether_type; + int is_ip = 0; +#ifdef IPFIREWALL_FORWARD + struct m_tag *fwd_tag; +#endif + snap = 0; error = -1; /* Default error if not error == 0 */ @@ -2967,6 +2972,7 @@ #ifdef INET6 case ETHERTYPE_IPV6: #endif /* INET6 */ + is_ip = 1; break; default: /* @@ -3024,6 +3030,30 @@ if (*mp == NULL) return (error); + +#ifdef IPFIREWALL_FORWARD + /* + * Did the firewall want to forward it somewhere? + * If so, let the ip stack handle it. + */ + if (i == 0 args.next_hop != NULL + is_ip /* src != NULL */) { + + fwd_tag = m_tag_get(PACKET_TAG_IPFORWARD, + sizeof(struct sockaddr_in), M_NOWAIT); + if (fwd_tag == NULL) + goto drop; + bcopy(args.next_hop, (fwd_tag+1), + sizeof(struct sockaddr_in)); + m_tag_prepend(*mp, fwd_tag); + + if (in_localip(args.next_hop-sin_addr)) + (*mp)-m_flags |= M_FASTFWD_OURS; + ether_demux(src, *mp); + return (NULL); + } +#endif +
Re: layer2 ipfw 'fwd' support
On Fri, Oct 8, 2010 at 10:55 AM, Eduardo Meyer dudu.me...@gmail.com wrote: On Thu, Oct 7, 2010 at 10:23 PM, Eduardo Meyer dudu.me...@gmail.com wrote: [SNIP] Luiz has added it to: http://loos.no-ip.org:280/lusca_bridge.diff I have tested and it works pretty well. I hope someone can add it to -HEAD, so we won't loose it again. With time, ipfw code changes and such great patches like Rizzo's and Julian's stop working one day. It's bad we miss such great functionality. Sounds like a reasonable request. I hope it is considered. Thank you again everyone envolved. Thanks goes to you for your persistence in getting this working. Adrian / Luiz / Julian, With this patch fwd does it's job on L2, ordinary proxy works like a charm. But TPROXY won't work. It would be perfect to have both features together. If you can suggest any further tests or changes I will be pleased to test. To be clear, are we getting to the point of having the capability in ipfw of doing something like this in pf: ... pass in quick on $INT_IF route-to lo0 inet proto tcp from any to 127.0.0.1 port 3128 keep state ... ...thus allowing true, transparent proxying? I really thought that this was possible already with ipfw :( I need to do some more reading... I would be very interested in obtaining details on your final setup, once everything is in place and fully functioning :) -Brandon ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: layer2 ipfw 'fwd' support
On Thu, Oct 7, 2010 at 12:19 AM, Julian Elischer jul...@freebsd.org wrote: On 10/6/10 12:06 PM, Eduardo Meyer wrote: On Tue, Oct 5, 2010 at 5:31 PM, Julian Elischerjul...@freebsd.org wrote: On 10/5/10 12:56 PM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 6:23 PM, Julian Elischerjul...@freebsd.org wrote: On 10/4/10 12:18 PM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 3:35 PM, Julian Elischerjul...@freebsd.org wrote: On 10/4/10 10:16 AM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 2:02 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Mon, Oct 4, 2010 at 9:44 AM, Eduardo Meyerdudu.me...@gmail.com wrote: Hello, In the past I have used this patch by Luigi Rizzo, which helped me well. http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html I tried with a friend to port it to -STABLE, but we were not able to find out what has replaced mt_tag. Also on ip_input.c we dirty hacked to following piece of code: #ifdef IPFIREWALL_FORWARD if (m-m_flags M_FASTFWD_OURS) { m-m_flags= ~M_FASTFWD_OURS; goto pass; /* XXX was 'ours' - SHOULD WE MODIFY IT HERE */ } if ((dchg = (m_tag_find(m, PACKET_TAG_IPFORWARD, NULL) != NULL)) != 0) { /* * Directly ship the packet on. This allows forwarding * packets originally destined to us to some other directly * connected host. */ ip_forward(m, dchg); return; } #endif /* IPFIREWALL_FORWARD */ And this is something we are not sure if its correct. So my very obvious question is: Does anyone has a recent version of this patch to share? Can anyone familiar with ipfw source code help me with that? I'm certainly not an expert, but I wonder if the patch your referring to is still required? Can you provide more detail about your particular application? -Brandon Yes, its still required since ipfw fwd ignores layer2 frames. The application is the very same: squid. I mean, Lusca in fact (squid fork). Thank you for your interest. Cisco/Ironport have a patch that does this.. I had permission to bring it back when I worked there but never got it committed. Adrian, was it part of the set I gave you? Hello Elischer, Was this made public? I hope Chadd has some good news. In fact I tent to use with Lusca in tproxy mode. I bet this is the only missing piece of software. I just dug up my old changes. do you want to fwd from a bridge? or what? (it makes a difference what patches are needed) If you want to fwd from a bridge to make a transparent layer 2 proxy, this may help.. Here are parts of it that may be relevent: these are old (2007 I think) but may be of use still. adrian had the full set at ==quote adrian= The stuff is in p4 now, but I haven't tested it out at all. //depo/projects/adrian_spoof_clientip/ I -think-. == end quote=== Index: net/if_bridge.c === RCS file: /usr/local/cvsroot/freebsd/src/sys/net/if_bridge.c,v retrieving revision 1.107 diff -u -r1.107 if_bridge.c --- net/if_bridge.c 6 Nov 2007 23:01:42 - 1.107 +++ net/if_bridge.c 28 Nov 2007 06:59:10 - @@ -2908,6 +2908,11 @@ struct ip *ip; struct llc llc1; u_int16_t ether_type; + int is_ip = 0; +#ifdef IPFIREWALL_FORWARD + struct m_tag *fwd_tag; +#endif + snap = 0; error = -1; /* Default error if not error == 0 */ @@ -2967,6 +2972,7 @@ #ifdef INET6 case ETHERTYPE_IPV6: #endif /* INET6 */ + is_ip = 1; break; default: /* @@ -3024,6 +3030,30 @@ if (*mp == NULL) return (error); + +#ifdef IPFIREWALL_FORWARD + /* + * Did the firewall want to forward it somewhere? + * If so, let the ip stack handle it. + */ + if (i == 0 args.next_hop != NULL + is_ip /* src != NULL */) { + + fwd_tag = m_tag_get(PACKET_TAG_IPFORWARD, + sizeof(struct sockaddr_in), M_NOWAIT); + if (fwd_tag == NULL) + goto drop; + bcopy(args.next_hop, (fwd_tag+1), + sizeof(struct sockaddr_in)); + m_tag_prepend(*mp, fwd_tag); + + if (in_localip(args.next_hop-sin_addr)) + (*mp)-m_flags |= M_FASTFWD_OURS; + ether_demux(src, *mp); + return (NULL); + } +#endif + if (DUMMYNET_LOADED (i == IP_FW_DUMMYNET)) {
Re: layer2 ipfw 'fwd' support
On Mon, Oct 4, 2010 at 6:23 PM, Julian Elischer jul...@freebsd.org wrote: On 10/4/10 12:18 PM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 3:35 PM, Julian Elischerjul...@freebsd.org wrote: On 10/4/10 10:16 AM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 2:02 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Mon, Oct 4, 2010 at 9:44 AM, Eduardo Meyerdudu.me...@gmail.com wrote: Hello, In the past I have used this patch by Luigi Rizzo, which helped me well. http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html I tried with a friend to port it to -STABLE, but we were not able to find out what has replaced mt_tag. Also on ip_input.c we dirty hacked to following piece of code: #ifdef IPFIREWALL_FORWARD if (m-m_flags M_FASTFWD_OURS) { m-m_flags= ~M_FASTFWD_OURS; goto pass; /* XXX was 'ours' - SHOULD WE MODIFY IT HERE */ } if ((dchg = (m_tag_find(m, PACKET_TAG_IPFORWARD, NULL) != NULL)) != 0) { /* * Directly ship the packet on. This allows forwarding * packets originally destined to us to some other directly * connected host. */ ip_forward(m, dchg); return; } #endif /* IPFIREWALL_FORWARD */ And this is something we are not sure if its correct. So my very obvious question is: Does anyone has a recent version of this patch to share? Can anyone familiar with ipfw source code help me with that? I'm certainly not an expert, but I wonder if the patch your referring to is still required? Can you provide more detail about your particular application? -Brandon Yes, its still required since ipfw fwd ignores layer2 frames. The application is the very same: squid. I mean, Lusca in fact (squid fork). Thank you for your interest. Cisco/Ironport have a patch that does this.. I had permission to bring it back when I worked there but never got it committed. Adrian, was it part of the set I gave you? Hello Elischer, Was this made public? I hope Chadd has some good news. In fact I tent to use with Lusca in tproxy mode. I bet this is the only missing piece of software. I just dug up my old changes. do you want to fwd from a bridge? or what? (it makes a difference what patches are needed) If you want to fwd from a bridge to make a transparent layer 2 proxy, this may help.. Here are parts of it that may be relevent: these are old (2007 I think) but may be of use still. adrian had the full set at ==quote adrian= The stuff is in p4 now, but I haven't tested it out at all. //depo/projects/adrian_spoof_clientip/ I -think-. == end quote=== Index: net/if_bridge.c === RCS file: /usr/local/cvsroot/freebsd/src/sys/net/if_bridge.c,v retrieving revision 1.107 diff -u -r1.107 if_bridge.c --- net/if_bridge.c 6 Nov 2007 23:01:42 - 1.107 +++ net/if_bridge.c 28 Nov 2007 06:59:10 - @@ -2908,6 +2908,11 @@ struct ip *ip; struct llc llc1; u_int16_t ether_type; + int is_ip = 0; +#ifdef IPFIREWALL_FORWARD + struct m_tag *fwd_tag; +#endif + snap = 0; error = -1; /* Default error if not error == 0 */ @@ -2967,6 +2972,7 @@ #ifdef INET6 case ETHERTYPE_IPV6: #endif /* INET6 */ + is_ip = 1; break; default: /* @@ -3024,6 +3030,30 @@ if (*mp == NULL) return (error); + +#ifdef IPFIREWALL_FORWARD + /* + * Did the firewall want to forward it somewhere? + * If so, let the ip stack handle it. + */ + if (i == 0 args.next_hop != NULL + is_ip /* src != NULL */) { + + fwd_tag = m_tag_get(PACKET_TAG_IPFORWARD, + sizeof(struct sockaddr_in), M_NOWAIT); + if (fwd_tag == NULL) + goto drop; + bcopy(args.next_hop, (fwd_tag+1), + sizeof(struct sockaddr_in)); + m_tag_prepend(*mp, fwd_tag); + + if (in_localip(args.next_hop-sin_addr)) + (*mp)-m_flags |= M_FASTFWD_OURS; + ether_demux(src, *mp); + return (NULL); + } +#endif + if (DUMMYNET_LOADED (i == IP_FW_DUMMYNET)) { == Index: netinet/ip_fw2.c === RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v retrieving revision 1.178 diff -u -r1.178 ip_fw2.c --- netinet/ip_fw2.c 28 Oct 2007 17:12:47 -
Re: layer2 ipfw 'fwd' support
On Mon, Oct 4, 2010 at 2:02 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Mon, Oct 4, 2010 at 9:44 AM, Eduardo Meyer dudu.me...@gmail.com wrote: Hello, In the past I have used this patch by Luigi Rizzo, which helped me well. http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html I tried with a friend to port it to -STABLE, but we were not able to find out what has replaced mt_tag. Also on ip_input.c we dirty hacked to following piece of code: #ifdef IPFIREWALL_FORWARD if (m-m_flags M_FASTFWD_OURS) { m-m_flags = ~M_FASTFWD_OURS; goto pass; /* XXX was 'ours' - SHOULD WE MODIFY IT HERE */ } if ((dchg = (m_tag_find(m, PACKET_TAG_IPFORWARD, NULL) != NULL)) != 0) { /* * Directly ship the packet on. This allows forwarding * packets originally destined to us to some other directly * connected host. */ ip_forward(m, dchg); return; } #endif /* IPFIREWALL_FORWARD */ And this is something we are not sure if its correct. So my very obvious question is: Does anyone has a recent version of this patch to share? Can anyone familiar with ipfw source code help me with that? I'm certainly not an expert, but I wonder if the patch your referring to is still required? Can you provide more detail about your particular application? -Brandon Yes, its still required since ipfw fwd ignores layer2 frames. The application is the very same: squid. I mean, Lusca in fact (squid fork). Thank you for your interest. -- === Eduardo Meyer pessoal: dudu.me...@gmail.com profissional: ddm.farmac...@saude.gov.br ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: layer2 ipfw 'fwd' support
On 10/4/10 10:16 AM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 2:02 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Mon, Oct 4, 2010 at 9:44 AM, Eduardo Meyerdudu.me...@gmail.com wrote: Hello, In the past I have used this patch by Luigi Rizzo, which helped me well. http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html I tried with a friend to port it to -STABLE, but we were not able to find out what has replaced mt_tag. Also on ip_input.c we dirty hacked to following piece of code: #ifdef IPFIREWALL_FORWARD if (m-m_flags M_FASTFWD_OURS) { m-m_flags= ~M_FASTFWD_OURS; goto pass; /* XXX was 'ours' - SHOULD WE MODIFY IT HERE */ } if ((dchg = (m_tag_find(m, PACKET_TAG_IPFORWARD, NULL) != NULL)) != 0) { /* * Directly ship the packet on. This allows forwarding * packets originally destined to us to some other directly * connected host. */ ip_forward(m, dchg); return; } #endif /* IPFIREWALL_FORWARD */ And this is something we are not sure if its correct. So my very obvious question is: Does anyone has a recent version of this patch to share? Can anyone familiar with ipfw source code help me with that? I'm certainly not an expert, but I wonder if the patch your referring to is still required? Can you provide more detail about your particular application? -Brandon Yes, its still required since ipfw fwd ignores layer2 frames. The application is the very same: squid. I mean, Lusca in fact (squid fork). Thank you for your interest. Cisco/Ironport have a patch that does this.. I had permission to bring it back when I worked there but never got it committed. Adrian, was it part of the set I gave you? ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org
Re: layer2 ipfw 'fwd' support
On 10/4/10 12:18 PM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 3:35 PM, Julian Elischerjul...@freebsd.org wrote: On 10/4/10 10:16 AM, Eduardo Meyer wrote: On Mon, Oct 4, 2010 at 2:02 PM, Brandon Gooch jamesbrandongo...@gmail.comwrote: On Mon, Oct 4, 2010 at 9:44 AM, Eduardo Meyerdudu.me...@gmail.com wrote: Hello, In the past I have used this patch by Luigi Rizzo, which helped me well. http://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html I tried with a friend to port it to -STABLE, but we were not able to find out what has replaced mt_tag. Also on ip_input.c we dirty hacked to following piece of code: #ifdef IPFIREWALL_FORWARD if (m-m_flagsM_FASTFWD_OURS) { m-m_flags= ~M_FASTFWD_OURS; goto pass; /* XXX was 'ours' - SHOULD WE MODIFY IT HERE */ } if ((dchg = (m_tag_find(m, PACKET_TAG_IPFORWARD, NULL) != NULL)) != 0) { /* * Directly ship the packet on. This allows forwarding * packets originally destined to us to some other directly * connected host. */ ip_forward(m, dchg); return; } #endif /* IPFIREWALL_FORWARD */ And this is something we are not sure if its correct. So my very obvious question is: Does anyone has a recent version of this patch to share? Can anyone familiar with ipfw source code help me with that? I'm certainly not an expert, but I wonder if the patch your referring to is still required? Can you provide more detail about your particular application? -Brandon Yes, its still required since ipfw fwd ignores layer2 frames. The application is the very same: squid. I mean, Lusca in fact (squid fork). Thank you for your interest. Cisco/Ironport have a patch that does this.. I had permission to bring it back when I worked there but never got it committed. Adrian, was it part of the set I gave you? Hello Elischer, Was this made public? I hope Chadd has some good news. In fact I tent to use with Lusca in tproxy mode. I bet this is the only missing piece of software. I just dug up my old changes. do you want to fwd from a bridge? or what? (it makes a difference what patches are needed) If you want to fwd from a bridge to make a transparent layer 2 proxy, this may help.. Here are parts of it that may be relevent: these are old (2007 I think) but may be of use still. adrian had the full set at ==quote adrian= The stuff is in p4 now, but I haven't tested it out at all. //depo/projects/adrian_spoof_clientip/ I -think-. == end quote=== Index: net/if_bridge.c === RCS file: /usr/local/cvsroot/freebsd/src/sys/net/if_bridge.c,v retrieving revision 1.107 diff -u -r1.107 if_bridge.c --- net/if_bridge.c 6 Nov 2007 23:01:42 - 1.107 +++ net/if_bridge.c 28 Nov 2007 06:59:10 - @@ -2908,6 +2908,11 @@ struct ip *ip; struct llc llc1; u_int16_t ether_type; + int is_ip = 0; +#ifdef IPFIREWALL_FORWARD + struct m_tag *fwd_tag; +#endif + snap = 0; error = -1; /* Default error if not error == 0 */ @@ -2967,6 +2972,7 @@ #ifdef INET6 case ETHERTYPE_IPV6: #endif /* INET6 */ + is_ip = 1; break; default: /* @@ -3024,6 +3030,30 @@ if (*mp == NULL) return (error); + +#ifdef IPFIREWALL_FORWARD + /* + * Did the firewall want to forward it somewhere? + * If so, let the ip stack handle it. + */ + if (i == 0 args.next_hop != NULL + is_ip /* src != NULL */) { + + fwd_tag = m_tag_get(PACKET_TAG_IPFORWARD, + sizeof(struct sockaddr_in), M_NOWAIT); + if (fwd_tag == NULL) + goto drop; + bcopy(args.next_hop, (fwd_tag+1), + sizeof(struct sockaddr_in)); + m_tag_prepend(*mp, fwd_tag); + + if (in_localip(args.next_hop-sin_addr)) + (*mp)-m_flags |= M_FASTFWD_OURS; + ether_demux(src, *mp); + return (NULL); + } +#endif + if (DUMMYNET_LOADED (i == IP_FW_DUMMYNET)) { == Index: netinet/ip_fw2.c === RCS file: /usr/local/cvsroot/freebsd/src/sys/netinet/ip_fw2.c,v retrieving revision 1.178 diff -u -r1.178 ip_fw2.c --- netinet/ip_fw2.c28 Oct 2007 17:12:47 - 1.178 +++ netinet/ip_fw2.c28 Nov 2007 06:59:10 - @@ -3446,8 +3507,10 @@ case O_FORWARD_IP: { struct
Re: layer2 ipfw 'fwd' support
On Mon, Oct 04, 2010, Julian Elischer wrote: -Brandon Yes, its still required since ipfw fwd ignores layer2 frames. The application is the very same: squid. I mean, Lusca in fact (squid fork). Thank you for your interest. Cisco/Ironport have a patch that does this.. I had permission to bring it back when I worked there but never got it committed. Adrian, was it part of the set I gave you? I don't recall; but I'm happy to look at merging it into -head. I was more after L3 interception than L2 interception. Adrian ___ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to freebsd-ipfw-unsubscr...@freebsd.org