summaryrefslogtreecommitdiffstats
path: root/docs/brnf-faq.html
blob: e96a89252136c3a87c4df8cdf1dcf9080135b029 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
<!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>