Date: Fri, 15 Dec 2006 13:20:27 -0800 From: Julian Elischer <julian@elischer.org> To: Max Laier <max@love2party.net> Cc: freebsd-net@freebsd.org, Andre Oppermann <andre@freebsd.org> Subject: Re: addition to ipfw.. Message-ID: <4583119B.20608@elischer.org> In-Reply-To: <200612120045.41425.max@love2party.net> References: <457DCD47.5090004@elischer.org> <457DD658.7010707@freebsd.org> <457DE28D.1010106@elischer.org> <200612120045.41425.max@love2party.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Max, further to your comment.. Max Laier wrote: > On Monday 11 December 2006 23:58, Julian Elischer wrote: >> Andre Oppermann wrote: >>> Julian Elischer wrote: >>>> in ipfw layer 2 processing, the packet is passed to the firewall >>>> as if it was a layer 3 IP packet but the ether header is also made >>>> available. >>>> >>>> I would like to add something similar in the case where a vlan tag >>>> is also on the packet.. >>>> >>>> basically I have a change where: >>>> >>>> If we are processing layer 2 packets (in ether or bridge code) >>>> AND a sysctl says to do it, >>>> and it is a vlan packet, >>>> >>>> Then the vlan header is also held back so that the packet can be >>>> processed and examined as an IP packet. It is >>>> (in the same way the ether header is) reattached when the packet is >>>> accepted. >>>> >>>> This allows me to filter packets that are traversing my bridge, >>>> even though they are encapsulated in a vlan. >>>> >>>> I have patches to allow this. I need this function. does anyone >>>> else? >>> Please have the ipfw code examine the vlan tag in the mbuf instead of >>> fiddling with the mbuf contents. >> The ipfw will be ignoring the vlan contents.. the patch is to move the >> 'start of ip header' pointer past the vlan header.. (if asked) so that >> it can identifu the IP packet. >> >> part of the patch is to make sure all the code uses this pointer >> instead of the case now where some code uses it and some uses mtod(). >> >> This could be used in conjunction with vlan keyword that would look at >> the vlan header, but that is a different feature.. > > I understand you do have a patch? Let's see it, so we are clear what we > are talking about. I think that w/o a ipfw feature to identify the vlan > number, it is pretty useless. Of course, it would enable you to do some > basic sanity checks, but real filtering needs to know the vlan it is > concerned with. BTW, what speaks against plugging the bridge into the > vlan on either side and bridge the vlan interfaces together? I have placed the following patch files: http://www.freebsd.org/~julian/vlstrip-7.diff http://www.freebsd.org/~julian/vlstrip-6.diff which implement the ability to look within vlans when being used on a bridge. I have done SOME testing with this but would certainly appreciate another set of eyes.. the next change would be lyered on top of this change and would be the addition of a rule: ipfw add 100 {operation} ip from any to any vlan {vlan_id}[-{vlan_id}] e.g. ipfw add 1000 skipto 4000 ip from any to any vlan 100-200 This, as it is will probably not work for the cases where vlans are decoded by the hardware. I'm guessing that at some stage we need to add the ability to cope with that too.. I remember that someone added some capacity to do that to bpf recently.. (?) I think.. I hope I've found all the places where the old code cared that the ip header was teh first thing in the mbuf.. if you see any places where that is stil assumed, let me know. It's working for my testing here but I'm only using it to monitor traffic on a tap, so the packets are discarded anyhow. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4583119B.20608>