docs/brnf-faq.html - external/ebtables - Gitiles

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
 <HTML>
 <HEAD>
 	<TITLE>Bridge-netfilter Frequently Asked Questions</TITLE>
 	<LINK rel="SHORTCUT ICON" href="">
 	<LINK rel="STYLESHEET" type="text/css" href="brnf.css">
 	<META name="description" content="Bridge-netfilter Frequently Asked Questions">
 	<META name="author" content="Bart De Schuymer">
 	<META name="keywords" content="Linux, netfilter, firewall, bridge, brouter, ebtables, iptables">
 	<META name="keywords" content="FAQ, kernel, ebtables, br-nf, brnf, bridge-nf, ethernet, nat, chains, rules, tables">
 </HEAD>
 <BODY>
 	<DIV class="banner" align="center">
 		<H1>Bridge-netfilter Frequently (and less frequently) Asked Questions</H1>
 	</DIV>
 	<A name="top"></A>
 	<P>Last modified: January 02, 2004</P>
 	<H2>Questions</H2>
 	<OL>
 		<LI class="question"><A href="#quiz0">Connection tracking</A></LI>
 		<LI class="question"><A href="#quiz1">General</A></LI>
 	</OL>
 	<H2>Answers</H2>
 	<OL>
 		<LI class="question">
 			<B><A name="quiz0">Connection tracking</A></B>
 			<DL>
 				<DT>
 What happens when I enable connection tracking?
 				</DT>
 				<DD>
 By default, all IP packets will be seen by the connection
 tracking code. This code is called on the PF_INET/PRE_ROUTING
 and PF_INET/LOCAL_OUT hooks. For bridged packets, only the
 PRE_ROUTING connection tracking is important.
 				</DD>
 			</DL>
 			<DL>
 				<DT>
 What are the disadvantages of connection tracking on a bridging
 firewall?
 				</DT>
 				<DD>
 					<OL>
 						<LI>
 For an IP packet entering a bridge device, connection tracking
 is called before the bridge code decides what to do with the
 packet. This means that IP packets that will be discarded by
 the bridge code are tracked by connection tracking. For a router,
 the same is true, but a bridge also sees the traffic between
 hosts on the same side of a network. It's possible to prevent
 these packets from being seen by connection tracking: you can
 either drop them in the ebtables nat PREROUTING chain or use the
 iptables NOTRACK target.
 						</LI>
 						<LI>
 Fragmented IP packets (typically UDP traffic like NFS) are
 defragmented by the connection tracking code and refragmented
 before sending them out. This slows down traffic, but the
 transparancy of the firewall isn't diminished.
 						</LI>
 					</OL>
 				</DD>
 			</DL>
 			<A class=navbar href="#top">[Back to the top]</A>
 			<HR>
 		</LI>
 		<LI class="question">
 			<B><A name="quiz1">General</A></B>
 			<DL>
 				<DT>
 What happens with IP DNAT on a to be bridged packet?
 				</DT>
 				<DD>
 If IP DNAT happened then the bridge-nf code asks the routing
 table where the packet should be sent. If it has to be sent
 over another device (not the bridge device) then the packet is
 routed (an implicit redirect). If the routing table sends the
 packet to the bridge device, then the packet is bridged but the
 MAC destination is correctly changed.
 				</DD>
 			</DL>
 			<DL>
 				<DT>
 How can I disable bridge-nf?
 				</DT>
 				<DD>
 If you don't want iptables and arptables to see bridged traffic,
 you can disable bridge-nf in the 2.6 kernel at compile time by
 disabling "Bridged IP/ARP packets filtering".
 				</DD>
 			</DL>
 			<DL>
 				<DT>
 Can I disable/enable bridge-nf specifics on-the-fly?
 				</DT>
 				<DD>
 As of kernel version 2.6.1, there are three sysctl entries for
 bridge-nf behavioral control (they can be found under
 /proc/sys/net/bridge/):
 					<UL>
 						<LI>
 bridge-nf-call-arptables - pass (1) or don't pass (0) bridged
 ARP traffic to arptables' FORWARD chain.
 						</LI>
 						<LI>
 bridge-nf-call-iptables - pass (1) or don't pass (0) bridged
 IPv4 traffic to iptables' chains.
 						</LI>
 						<LI>
 bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0)
 bridged vlan-tagged ARP/IP traffic to arptables/iptables.
 						</LI>
 					</UL>
 				</DD>
 			</DL>

 			<DL>
 				<DT>
 Do {ip,arp}tables see VLAN tagged IP/ARP traffic on an untagged
 bridge?
 				</DT>
 				<DD>
 Yes. Kernel versions 2.6.0-test7 and above have this
 functionality. For disabling this, see the above question.
 				</DD>
 				<DT>
 How do I let vlan-tagged traffic go through a vlan bridge port
 and the other traffic through a non-vlan bridge port?
 				</DT>
 				<DD>
 Suppose eth0 and eth0.15 are ports of br0. Without countermeasures
 all traffic, including traffic vlan-tagged with tag 15, entering
 the physical device eth0 will go through the bridge port eth0. To
 make the 15-tagged traffic go through the eth0.15 bridge port, use
 the following ebtables rule:
 <PRE>
 ebtables -t broute -A BROUTING -i eth0 --vlan-id 15 -j DROP
 </PRE>
 With the above rule, 15-tagged traffic will enter the bridge on
 the physical device eth0, will then be brouted and enter the
 bridge port eth0.15 after which it is bridged. The packet thus
 enters the BROUTING chain twice, the first time with input
 device eth0 and the second time with input device eth0.15. The
 other chains are only traversed once. All other traffic will
 be bridged with input device eth0.
 				</DD>
 				<DT>
 Do {ip,arp}tables see encapsulated 802.2/802.3 IP/ARP traffic?
 				</DT>
 				<DD>
 No. Adding this shouldn't be that hard though.
 				</DD>
 				<DT>
 Does ip6tables see any bridge IPv6 traffic?
 				</DT>
 				<DD>
 Nope, it's on the todo-list.
 				</DD>
 			</DL>
 			<A class=navbar href="#top">[Back to the top]</A>
 			<HR>
 		</LI>
 	</OL>
 </BODY>
 </HTML>
	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
	<HTML>
	<HEAD>
	<TITLE>Bridge-netfilter Frequently Asked Questions</TITLE>
	<LINK rel="SHORTCUT ICON" href="">
	<LINK rel="STYLESHEET" type="text/css" href="brnf.css">
	<META name="description" content="Bridge-netfilter Frequently Asked Questions">
	<META name="author" content="Bart De Schuymer">
	<META name="keywords" content="Linux, netfilter, firewall, bridge, brouter, ebtables, iptables">
	<META name="keywords" content="FAQ, kernel, ebtables, br-nf, brnf, bridge-nf, ethernet, nat, chains, rules, tables">
	</HEAD>
	<BODY>
	<DIV class="banner" align="center">
	<H1>Bridge-netfilter Frequently (and less frequently) Asked Questions</H1>
	</DIV>
	<A name="top"></A>
	<P>Last modified: January 02, 2004</P>
	<H2>Questions</H2>
	<OL>
	<LI class="question"><A href="#quiz0">Connection tracking</A></LI>
	<LI class="question"><A href="#quiz1">General</A></LI>
	</OL>
	<H2>Answers</H2>
	<OL>
	<LI class="question">
	<B><A name="quiz0">Connection tracking</A></B>
	<DL>
	<DT>
	What happens when I enable connection tracking?
	</DT>
	<DD>
	By default, all IP packets will be seen by the connection
	tracking code. This code is called on the PF_INET/PRE_ROUTING
	and PF_INET/LOCAL_OUT hooks. For bridged packets, only the
	PRE_ROUTING connection tracking is important.
	</DD>
	</DL>
	<DL>
	<DT>
	What are the disadvantages of connection tracking on a bridging
	firewall?
	</DT>
	<DD>
	<OL>
	<LI>
	For an IP packet entering a bridge device, connection tracking
	is called before the bridge code decides what to do with the
	packet. This means that IP packets that will be discarded by
	the bridge code are tracked by connection tracking. For a router,
	the same is true, but a bridge also sees the traffic between
	hosts on the same side of a network. It's possible to prevent
	these packets from being seen by connection tracking: you can
	either drop them in the ebtables nat PREROUTING chain or use the
	iptables NOTRACK target.
	</LI>
	<LI>
	Fragmented IP packets (typically UDP traffic like NFS) are
	defragmented by the connection tracking code and refragmented
	before sending them out. This slows down traffic, but the
	transparancy of the firewall isn't diminished.
	</LI>
	</OL>
	</DD>
	</DL>
	<A class=navbar href="#top">[Back to the top]</A>
	<HR>
	</LI>
	<LI class="question">
	<B><A name="quiz1">General</A></B>
	<DL>
	<DT>
	What happens with IP DNAT on a to be bridged packet?
	</DT>
	<DD>
	If IP DNAT happened then the bridge-nf code asks the routing
	table where the packet should be sent. If it has to be sent
	over another device (not the bridge device) then the packet is
	routed (an implicit redirect). If the routing table sends the
	packet to the bridge device, then the packet is bridged but the
	MAC destination is correctly changed.
	</DD>
	</DL>
	<DL>
	<DT>
	How can I disable bridge-nf?
	</DT>
	<DD>
	If you don't want iptables and arptables to see bridged traffic,
	you can disable bridge-nf in the 2.6 kernel at compile time by
	disabling "Bridged IP/ARP packets filtering".
	</DD>
	</DL>
	<DL>
	<DT>
	Can I disable/enable bridge-nf specifics on-the-fly?
	</DT>
	<DD>
	As of kernel version 2.6.1, there are three sysctl entries for
	bridge-nf behavioral control (they can be found under
	/proc/sys/net/bridge/):
	<UL>
	<LI>
	bridge-nf-call-arptables - pass (1) or don't pass (0) bridged
	ARP traffic to arptables' FORWARD chain.
	</LI>
	<LI>
	bridge-nf-call-iptables - pass (1) or don't pass (0) bridged
	IPv4 traffic to iptables' chains.
	</LI>
	<LI>
	bridge-nf-filter-vlan-tagged - pass (1) or don't pass (0)
	bridged vlan-tagged ARP/IP traffic to arptables/iptables.
	</LI>
	</UL>
	</DD>
	</DL>

	<DL>
	<DT>
	Do {ip,arp}tables see VLAN tagged IP/ARP traffic on an untagged
	bridge?
	</DT>
	<DD>
	Yes. Kernel versions 2.6.0-test7 and above have this
	functionality. For disabling this, see the above question.
	</DD>
	<DT>
	How do I let vlan-tagged traffic go through a vlan bridge port
	and the other traffic through a non-vlan bridge port?
	</DT>
	<DD>
	Suppose eth0 and eth0.15 are ports of br0. Without countermeasures
	all traffic, including traffic vlan-tagged with tag 15, entering
	the physical device eth0 will go through the bridge port eth0. To
	make the 15-tagged traffic go through the eth0.15 bridge port, use
	the following ebtables rule:
	<PRE>
	ebtables -t broute -A BROUTING -i eth0 --vlan-id 15 -j DROP
	</PRE>
	With the above rule, 15-tagged traffic will enter the bridge on
	the physical device eth0, will then be brouted and enter the
	bridge port eth0.15 after which it is bridged. The packet thus
	enters the BROUTING chain twice, the first time with input
	device eth0 and the second time with input device eth0.15. The
	other chains are only traversed once. All other traffic will
	be bridged with input device eth0.
	</DD>
	<DT>
	Do {ip,arp}tables see encapsulated 802.2/802.3 IP/ARP traffic?
	</DT>
	<DD>
	No. Adding this shouldn't be that hard though.
	</DD>
	<DT>
	Does ip6tables see any bridge IPv6 traffic?
	</DT>
	<DD>
	Nope, it's on the todo-list.
	</DD>
	</DL>
	<A class=navbar href="#top">[Back to the top]</A>
	<HR>
	</LI>
	</OL>
	</BODY>
	</HTML>