Re: addition to ipfw..

On Friday 15 December 2006 22:20, Julian Elischer wrote:
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..

There is M_VLANTAG and m_pkthdr.ether_vtag for hardware support. You
could even reuse those for this. i.e. emulate hardware support for ipfw
in the pfil hook. If you want to look at the vlan tag later, you can
always use those then.

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.

I don't like the implementation for this reason. It feels hackish to me.
What is the reason that you didn't duplicate the ethernet header approach
in ip_fw_pfil.c? Speed? Did you measure? It is certainly easier to
properly strip off the vlan header in the pfil hook code and reattach it
when done (or trust the hardware to do it - if M_VLANTAG was set in the
first place).

As an aside, I agree that the mtod mania isn't that great either and we
should probably do away with it. But that's orthogonal to the vlan
handling - I just don't like that to be pulled into *IP*fw. This might
just be me, however.

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.

--
/"\ Best regards, | mlaier@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Attachment: pgpG0qvYzTm95.pgp
Description: PGP signature

Relevant Pages

  • Re: [was] addition to ipfw (read vlans from bridge)..
    ... into the packet as well as the packet, then yes I like that idea, ... At the moment I plan the ipfw code to be unaware of vlan headers. ... What we need to do is make a convention so that vlan tags are always ...
    (freebsd-net)
  • Re: addition to ipfw..
    ... I would like to add something similar in the case where a vlan ... tag is also on the packet.. ... Then the vlan header is also held back so that the packet can be ... This allows me to filter packets that are traversing my bridge, ...
    (freebsd-net)
  • Re: addition to ipfw..
    ... I would like to add something similar in the case where a vlan tag ... is also on the packet.. ... Then the vlan header is also held back so that the packet can be ... This allows me to filter packets that are traversing my bridge, ...
    (freebsd-net)
  • Re: addition to ipfw..
    ... I would like to add something similar in the case where a vlan tag ... is also on the packet.. ... Then the vlan header is also held back so that the packet can be ... Of course, it would enable you to do some basic sanity checks, but real filtering needs to know the vlan it is concerned with. ...
    (freebsd-net)
  • Re: addition to ipfw..
    ... as if it was a layer 3 IP packet but the ether header is also made ... I would like to add something similar in the case where a vlan tag ... is also on the packet.. ... Then the vlan header is also held back so that the packet can be ...
    (freebsd-net)