Date: Sat, 27 Oct 2018 21:09:46 +0300 From: Victor Gamov <vit@otcnet.ru> To: freebsd-net@freebsd.org Subject: Re: ipfw on bridge connecting vlans Message-ID: <9326bc98-ec90-b68f-f08d-b2f021bb2f90@otcnet.ru> In-Reply-To: <ae10c802-3b26-900c-bc35-2ea6c1d6102e@grosbein.net> References: <36cd661e-ca54-be94-fd64-01ee768d5053@otcnet.ru> <9b8d8c04-8e3e-b148-8a08-135d6ac1785d@grosbein.net> <49c4193a-d38c-eff8-3ab8-25b103c2dcba@otcnet.ru> <45f4881e-3a02-5a37-1e77-45b530460fad@grosbein.net> <64d0ceec-2d0c-9086-04e9-72a5f4f678c2@otcnet.ru> <ae10c802-3b26-900c-bc35-2ea6c1d6102e@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/10/2018 21:02, Eugene Grosbein wrote: > 28.10.2018 0:48, Victor Gamov wrote: > >> On 27/10/2018 19:33, Eugene Grosbein wrote: >>> 27.10.2018 23:26, Victor Gamov wrote: >>> >>> [skip] >>> >>>>> net.link.bridge.pfil_member=1 makes frames enter ruleset as >>>>> incoming from bridge member, zero disables this pass. >>>>> >>>>> net.link.bridge.ipfw=1 makes frames enter ruleset again as >>>>> incoming from bridge interface itself without distinction of >>>>> bridge member, and for forwarded frames enter ruleset one more >>>>> time as outgoing from the bridge itself. >>>>> >>>>> And frame enters ruleset one MORE time as outgoing from bridge >>>>> member if net.link.bridge.pfil_member=1. >>> >>> (*) >>> >>>> With current configs I have unexpected behavior when multicast >>>> received via unneeded vlan300 not blocked by rule 9000 and bad >>>> traffic bridged into all bridge members. >>>> >>>> So if when net.link.bridge.pfil_member=1 then I can check incoming >>>> and outgoing bridge members as expected? I'll try it later, >>>> thanks >>>> >>>> >>>> Is it possible the following config with >>>> net.link.bridge.pfil_member=1 ? >>> >>> Yes, it should be. >>> >>>> table allow239 create type iface table allow239 add vlan400 3000 >>>> allow ip from any to 239.0.0.10 recv vlan100 xmit table(allow239) >>> >>> You also should add the "out" keyword to this rule for performance >>> and clearness because only outgoing frames have "xmit" attribute to >>> check, so this rule is not tried for incoming frames (it won't match >>> them anyway). >>> >>>> It's still very interesting to know full packet path via all >>>> interfaces (phy, vlan, bridge) and understand where/why ipfw >>>> triggered. For example why i need "allow via igb0"? It's because >>>> net.link.ether.ipfw=1? Can you explain it in details? >>> >>> See above (*). >> >> ok, frame path and ipfw as I see it. >> >> ===== >> 1000 allow ip from any to any via igb0 >> 1002 allow ip from any to any via igb2 >> >> 1100 deny ip from any to any mac-type 0x0806 via bridge2 >> 1102 allow ip from any to any via bridge2 >> >> 2000 allow ip from any to 239.0.0.10 in recv vlan200 >> >> 4000 allow ip from any to 239.0.0.10 out xmit table(allow239) >> >> 9000 deny ip from any to any via table(block239) >> >> 65000 allow ip from any to any >> ===== >> >> 1. tagged frame come to physical interface igb0. >> As I have net.link.ether.ipfw=1 then tagged frame checked by IPFW and I need >> 1000 allow ip from any to any via igb0 >> >> Frame passed via igb0 and untagged. >> >> >> 2. untagged frame appears on vlan100. >> Now I can get it via `tcpdump -i vlan100` >> >> Frame checked by IPFW on vlan100 because >> net.link.bridge.pfil_member=1 AND vlan100 is a bridge member >> ( net.link.ether.ipfw=1 is irrelevant? ) >> >> So I can pass/block traffic here. >> 2000 allow ip from any to 239.0.0.10 in recv vlan100 >> 9000 block ip from any to any via table(block239) >> Frame accepted on VLAN-100 >> >> >> 3. frame (untagged but still ethernet frame not IP packet) appears on bridge2 as incoming and checked by IPFW due net.link.bridge.ipfw=1. >> >> I block ARP but allow all other frames (1100 + 1102) >> >> >> 4. frame appears on all bridge-member vlans. >> Frame checked by IPFW on vlan300/vlan400 because >> net.link.bridge.pfil_member=1 AND vlan300/vlan400 is a bridge member >> >> So I can pass/block traffic here. >> 4000 allow ip from any to 239.0.0.10 out xmit table(allow239) >> 9000 block ip from any to any via table(block239) >> >> Passed frames tagged >> >> >> 5. tagged frame appears on igb2 >> As I have net.link.ether.ipfw=1 then tagged frame checked by IPFW and I need >> 1002 allow ip from any to any via igb2 >> >> >> Is this scheme is correct? >> >> > > Almost right with one exception: bridge considers ARP (and REVARP) packets special > and passed them through the ruleset only when sysctl net.link.bridge.ipfw_arp=1; yes it enabled. Thanks Eugene! -- CU, Victor Gamov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9326bc98-ec90-b68f-f08d-b2f021bb2f90>