Date: Sat, 27 Oct 2018 20:48:02 +0300 From: Victor Gamov <vit@otcnet.ru> To: freebsd-net@freebsd.org Subject: Re: ipfw on bridge connecting vlans Message-ID: <64d0ceec-2d0c-9086-04e9-72a5f4f678c2@otcnet.ru> In-Reply-To: <45f4881e-3a02-5a37-1e77-45b530460fad@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- CU, Victor Gamov
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?64d0ceec-2d0c-9086-04e9-72a5f4f678c2>