Re: 5.4 -- bridging, ipfw, dot1q
Dan Mahoney, System Admin wrote: should be in -net not -hackers cc's changed accordingly.. After all, the demuxing is nothing more than ignoring a few extra bits at the beginning of the packet. Which all my BPF stuff is doing nicely. Snort, trafshow, etc all work fine and don't seem to choke on the extra frames. I'd personally just be happy if ipfw was smart enough to know that if I was using ip-type rules on something that's not ip...that it would handle the demuxing automagically. i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan via em1 or maybe i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan-as-inet via em1 Hi Dan. What it comes down to is just that no-one who has worked in ipfw has had your particular problem to solve. O/S gets done when people have a particular problem to solve. As for demultiplexing, well, you COULD pass it out to a netgraph node that strips off the header and stores the info in a tag, and then passes it back to ipfw, but I don't know how the details would work. (I haven't been in ifpw since it was rewritten). Alternatively you could use netgraph bridging and tehnetgraph vlan node type to achieve some sort of stripping.. (Once again, I'm just pointing you in this direction, not providing a full answer.) In 6.x netgraph has more options for this sort of thing with a direct interface between ipfw and netgraph. So, if you want to fix it, you could either do some work on ipfw or do some work on netgraph, but either way you'll probably need to do some work. Julian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4 -- bridging, ipfw, dot1q
On Fri, 12 Aug 2005, Luigi Rizzo wrote: On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote: Hi, I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to see the IP headers. Your most reasonable option would be to write a new ipufw2 opcode, say something like 'vlan-decap x-y', which succeeds if the packet has a vlan header in the range x to y, and in this case skips the VLAN header, tries to re-parse the header fields as in the beginning of ip_fw_chk() after the section /* * Collect parameters into local variables for faster matching. */ and then continues. It's not a lot of code, in the worst case you can just cut&paste the relevant 50-60 lines from the beginning of the code (though of course it would be nice to rearrange the code to reduce duplication). By doing this you can do something like ipfw add skipto 1000 vlan-decap 1-50 and then process vlans 1 to 50 at line 1000. Maybe it is a good idea to split the vlan-id matching and the decapsulation. Isn't it posible to cheat using vlan(4) interface ? I think it's possible to create them in order to use its code to zap the VLAN header and then use ipfw to filter on these vlan(4) interfaces. This isn't more than a workaround, but it might help. After all, the demuxing is nothing more than ignoring a few extra bits at the beginning of the packet. Which all my BPF stuff is doing nicely. Snort, trafshow, etc all work fine and don't seem to choke on the extra frames. I'd personally just be happy if ipfw was smart enough to know that if I was using ip-type rules on something that's not ip...that it would handle the demuxing automagically. i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan via em1 or maybe i.e. ipfw add 100 deny ip from any to 192.168.1.1 mac-type vlan-as-inet via em1 assuming mac-type vlan is, of course, dot1q trunk traffic. or better still... ipfw add 200 deny ip from any to 10.2.2.2 mac-type vlan vlan-id 400 via em1 I'd also really like it if non-bridged interfaces kept their arp table separate from normal interfaces -- but that's a separate issue I'm experiencing when the management subnet (on a dedicated non-bridged nic) also happens to be one of the vlans within the dot1q trunk. A spanning tree daemon (user or kernelspace) wouldn't be bad either. well it would be painful to configure, because the number of vlans is (according to what Dan says) is large, and he would have to define N vlan interfaces on each of the physical ones, then define N bridges between the corresponding vlans (and i think there is a limit on how large N can be). It's worse than that. The device has four bridged interfaces. One up, three down to three switches. Each switch holds 24 vlans. That QUICKLY becomes a nightmare when bridging actually works without doing this. It's just ipfw saying "nope, there's no possible way for me to look Additionally demuxing incoming packets would take O(N) time. cheers luigi -- "I hate Windows" -Tigerwolf, Anthrocon 2004 Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4 -- bridging, ipfw, dot1q
On Sat, Aug 13, 2005 at 12:49:56AM +0200, Jeremie Le Hen wrote: > Hi, > > > I am afraid the existing code cannot help you. > > The packets you see are encapsulated in 802.1q aka VLAN frames, > > and since ipfw2 does not try to decapsulate the packets, you > > don't get to see the IP headers. > > > > Your most reasonable option would be to write a new ipufw2 opcode, > > say something like 'vlan-decap x-y', which succeeds if the packet has > > a vlan header in the range x to y, and in this case skips the VLAN header, > > tries to re-parse the header fields as in the beginning of > > ip_fw_chk() after the section > > > > /* > > * Collect parameters into local variables for faster matching. > > */ > > > > and then continues. > > It's not a lot of code, in the worst case you can just cut&paste > > the relevant 50-60 lines from the beginning of the code > > (though of course it would be nice to rearrange the code to > > reduce duplication). > > > > By doing this you can do something like > > > > ipfw add skipto 1000 vlan-decap 1-50 > > > > and then process vlans 1 to 50 at line 1000. > > Maybe it is a good idea to split the vlan-id matching and the decapsulation. > > Isn't it posible to cheat using vlan(4) interface ? I think it's > possible to create them in order to use its code to zap the VLAN header > and then use ipfw to filter on these vlan(4) interfaces. This isn't > more than a workaround, but it might help. well it would be painful to configure, because the number of vlans is (according to what Dan says) is large, and he would have to define N vlan interfaces on each of the physical ones, then define N bridges between the corresponding vlans (and i think there is a limit on how large N can be). Additionally demuxing incoming packets would take O(N) time. cheers luigi ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4 -- bridging, ipfw, dot1q
Hi, > I am afraid the existing code cannot help you. > The packets you see are encapsulated in 802.1q aka VLAN frames, > and since ipfw2 does not try to decapsulate the packets, you > don't get to see the IP headers. > > Your most reasonable option would be to write a new ipufw2 opcode, > say something like 'vlan-decap x-y', which succeeds if the packet has > a vlan header in the range x to y, and in this case skips the VLAN header, > tries to re-parse the header fields as in the beginning of > ip_fw_chk() after the section > > /* > * Collect parameters into local variables for faster matching. > */ > > and then continues. > It's not a lot of code, in the worst case you can just cut&paste > the relevant 50-60 lines from the beginning of the code > (though of course it would be nice to rearrange the code to > reduce duplication). > > By doing this you can do something like > > ipfw add skipto 1000 vlan-decap 1-50 > > and then process vlans 1 to 50 at line 1000. > Maybe it is a good idea to split the vlan-id matching and the decapsulation. Isn't it posible to cheat using vlan(4) interface ? I think it's possible to create them in order to use its code to zap the VLAN header and then use ipfw to filter on these vlan(4) interfaces. This isn't more than a workaround, but it might help. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4 -- bridging, ipfw, dot1q
I am afraid the existing code cannot help you. The packets you see are encapsulated in 802.1q aka VLAN frames, and since ipfw2 does not try to decapsulate the packets, you don't get to see the IP headers. Your most reasonable option would be to write a new ipufw2 opcode, say something like 'vlan-decap x-y', which succeeds if the packet has a vlan header in the range x to y, and in this case skips the VLAN header, tries to re-parse the header fields as in the beginning of ip_fw_chk() after the section /* * Collect parameters into local variables for faster matching. */ and then continues. It's not a lot of code, in the worst case you can just cut&paste the relevant 50-60 lines from the beginning of the code (though of course it would be nice to rearrange the code to reduce duplication). By doing this you can do something like ipfw add skipto 1000 vlan-decap 1-50 and then process vlans 1 to 50 at line 1000. Maybe it is a good idea to split the vlan-id matching and the decapsulation. cheers luigi On Fri, Aug 12, 2005 at 05:07:13AM -0400, Dan Mahoney, System Admin wrote: > Note: I posted this to questions@ earlier, but upon further investigation > of the issue, I realize that I basically need a "hack". > > Warning, long. > > My original question: > > [begin] > > I'm setting up a bridging firewall where the packets are passing through > on dot1q trunks. Figure sixty or so. Too many to create separate > interfaces. > > The bridge works. Packet counts in the default match rule work (so I > assume the bridge at least sees the packets). > > Problem is, any "reasonable" rules (such as those which actually say to > block traffic by ip or port or anything) aren't working > at all. Not even logging counts. > > Setting the "bridged" flag doesn't seem to help. > > My only guess is that ipfw doesn't have the brains to look beyond the VLAN > tags. Is this the case? Is this supported under 4.x (I'm using 5, but > can downgrade), or is there any way AT ALL that I can get this to work? > > As a note, snort and trafshow and everything else work fine analyzing the > bridge traffic, it seems only the kernel has an issue. > > [end] > > Now my plea to hackers@: > > >From what I can see, the packet type is mac, and that's the only rules > that match. I'm not 100 percent sure if this is because of the point at > which this is being received, or because of the dot1q headers. I have to > assume it's the headers because, well, otherwise putting ipfw on a bridge > would seem pretty silly to me. > > I basically need minor mods done to the kernel code so that dot1q trunked > traffic seen through a bridge is seen by ipfw rules (and matched by the > same)... > > I basically assume this doesn't work because of this post made by Ted > Middelstadt a couple years ago > > http://groups-beta.google.com/group/mailing.freebsd.questions/browse_frm/thread/79d023785ddc58ed/4e280a013b6325d4?tvc=1&q=vlan+trunk+ipfw+bridge+ted&hl=en#4e280a013b6325d4 > > Of course, he says this: > > The biggest loss of NOT having an Ethernet-specific ipfw-like filtering > program, is that there's no convenient vehicle to use for adding in code > for filtering based on MAC addresses, which is certainly the domain of > a bridge. > > And ipfw2 basically addresses this. > > This is what I see on my bridged packets with log: > > Aug 11 23:38:43 fwi kernel: ipfw: 360 Accept MAC in via em1 > > I've tried every possible combination of arguments to ipfw which seem to > match. > None are hitting: > > 00305 00 count ip from any to 56.199.242.178 layer2 > mac-type 0x8100 > 00305 00 count ip from any to 56.199.242.178 mac-type > 0x8100 > 00305 00 count ip from any to 56.199.242.178 mac-type > 0x8100 > 00305 00 count ip from any to 56.199.242.178 mac-type > 0x8100 via em1 > 00305 00 count ip from any to 56.199.242.82 mac-type > 0x8100 via em1 > 00305 00 count ip from any to 56.199.242.82 layer2 > mac-type 0x > > If this is possible with standard vanilla bridging and standard ipfw, > please let me know, of course. I'm guessing dot1q encapsulated traffic > just doesn't match this. I can match traffic with an "any to any mac-type > vlan" or an "any to any layer2" rule. But I think I can't match on more > specific criteria (like an IP address) because the ipfw layer sees it as > non-ip traffic, and doesn't even attempt to match it (even though I'm > telling it specifically to do so), so it falls into the "silently passed" > portion. > > I don't know c. And this is a bad time and place to learn. The kernel > code is also fairly streamlined, and I *really* don't have the time to > learn structures and the like. It's on my long-term to-do list, I swear. > > Otherwise, I'm relatively sure this is less than an hour's worth of work, > please someone let me k
5.4 -- bridging, ipfw, dot1q
Note: I posted this to questions@ earlier, but upon further investigation of the issue, I realize that I basically need a "hack". Warning, long. My original question: [begin] I'm setting up a bridging firewall where the packets are passing through on dot1q trunks. Figure sixty or so. Too many to create separate interfaces. The bridge works. Packet counts in the default match rule work (so I assume the bridge at least sees the packets). Problem is, any "reasonable" rules (such as those which actually say to block traffic by ip or port or anything) aren't working at all. Not even logging counts. Setting the "bridged" flag doesn't seem to help. My only guess is that ipfw doesn't have the brains to look beyond the VLAN tags. Is this the case? Is this supported under 4.x (I'm using 5, but can downgrade), or is there any way AT ALL that I can get this to work? As a note, snort and trafshow and everything else work fine analyzing the bridge traffic, it seems only the kernel has an issue. [end] Now my plea to hackers@: From what I can see, the packet type is mac, and that's the only rules that match. I'm not 100 percent sure if this is because of the point at which this is being received, or because of the dot1q headers. I have to assume it's the headers because, well, otherwise putting ipfw on a bridge would seem pretty silly to me. I basically need minor mods done to the kernel code so that dot1q trunked traffic seen through a bridge is seen by ipfw rules (and matched by the same)... I basically assume this doesn't work because of this post made by Ted Middelstadt a couple years ago http://groups-beta.google.com/group/mailing.freebsd.questions/browse_frm/thread/79d023785ddc58ed/4e280a013b6325d4?tvc=1&q=vlan+trunk+ipfw+bridge+ted&hl=en#4e280a013b6325d4 Of course, he says this: The biggest loss of NOT having an Ethernet-specific ipfw-like filtering program, is that there's no convenient vehicle to use for adding in code for filtering based on MAC addresses, which is certainly the domain of a bridge. And ipfw2 basically addresses this. This is what I see on my bridged packets with log: Aug 11 23:38:43 fwi kernel: ipfw: 360 Accept MAC in via em1 I've tried every possible combination of arguments to ipfw which seem to match. None are hitting: 00305 00 count ip from any to 56.199.242.178 layer2 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 00305 00 count ip from any to 56.199.242.178 mac-type 0x8100 via em1 00305 00 count ip from any to 56.199.242.82 mac-type 0x8100 via em1 00305 00 count ip from any to 56.199.242.82 layer2 mac-type 0x If this is possible with standard vanilla bridging and standard ipfw, please let me know, of course. I'm guessing dot1q encapsulated traffic just doesn't match this. I can match traffic with an "any to any mac-type vlan" or an "any to any layer2" rule. But I think I can't match on more specific criteria (like an IP address) because the ipfw layer sees it as non-ip traffic, and doesn't even attempt to match it (even though I'm telling it specifically to do so), so it falls into the "silently passed" portion. I don't know c. And this is a bad time and place to learn. The kernel code is also fairly streamlined, and I *really* don't have the time to learn structures and the like. It's on my long-term to-do list, I swear. Otherwise, I'm relatively sure this is less than an hour's worth of work, please someone let me know what it's worth to you and I'll make it happen. (While I'lll be happy with a quick hack, this really is something that should probably at least have a sysctl or hooks in ipfw or something -- assuming anyone else finds it useful). Thanks, Dan Mahoney -- "We need another cat. This one's retarded." -Cali, March 8, 2003 (3:43 AM) Dan Mahoney Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
