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
|
<!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: December 30, 2003</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. Patch ebtables-brnf-3-vs-2.4.22 and later patches
(for 2.4) have this functionality too.
</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>
|
