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
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
|
<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01//EN'
'http://www.w3.org/TR/html4/strict.dtd'>
<HTML>
<HEAD>
<TITLE>
ebtables/iptables interaction on a Linux-based bridge
</TITLE>
<META HTTP-EQUIV="Content-Type" CONTENT=
"text/html; charset=iso-8859-1">
<LINK REL="STYLESHEET" TYPE="text/css" HREF="br_fw_ia.css">
</HEAD>
<BODY>
<DIV CLASS="bar">
<DIV CLASS="shadow">
<H1 ALIGN="center">
ebtables/iptables interaction on a Linux-based bridge
</H1>
</DIV>
</DIV>
<H3>
<A NAME="top">Table of Contents</A>
</H3>
<OL>
<LI>
<A HREF="#section1">Introduction</A>
</LI>
<LI>
<A HREF="#section2">How frames traverse the
<EM>ebtables</EM> chains</A>
</LI>
<LI>
<A HREF="#section3">A machine used as a bridge and a
router (not a brouter)</A>
</LI>
<LI>
<A HREF="#section4">DNAT'ing bridged packets</A>
</LI>
<LI>
<A HREF="#section5">Chain traversal for bridged IP packets</A>
</LI>
<LI>
<A HREF="#section6">Using a bridge port in <EM>iptables</EM> rules</A>
</LI>
<LI>
<A HREF="#section7">Two possible ways for frames/packets
to pass through the <EM>iptables</EM> PREROUTING, FORWARD and
POSTROUTING chains</A>
</LI>
<LI>
<A HREF="#section8">IP DNAT in the <EM>iptables</EM> PREROUTING
chain on frames/packets entering on a bridge port</A>
</LI>
<LI>
<A HREF="#section9">Using the MAC module extension for
<EM>iptables</EM></A>
</LI>
<LI>
<A HREF="#section10">Using the <EM>iptables</EM> physdev match module for kernel 2.5</A>
</LI>
</OL>
<A NAME="section1"></A>
<P CLASS="section">
1. Introduction
</P>
<P>
This document describes how <EM>iptables</EM> and
<EM>ebtables</EM> filtering tables interact on a Linux-based bridge.<BR>
Getting a bridging firewall consists of patching the kernel source
code with one or two patches.
Kernels 2.5.39 and above only need the "br-nf-bds" patch, since ebtables has been integrated in the 2.5.x series.
For other kernels, you need to first apply the patch that adds <EM>ebtables</EM> support in the kernel.
The "br-nf-bds" patch makes bridged IP frames/packets go through the <EM>iptables</EM> chains.
<EM>Ebtables</EM> filters on the Ethernet layer, while <EM>iptables</EM>
only filters IP packets.<BR>
The explanations below will use the TCP/IP Network Model.
It should be noted that the br-nf-bds patch sometimes violates the
TCP/IP Network
Model. As will be seen later, it is possible, f.e., to do IP DNAT inside the Link Layer.<BR>
We want to note that we are perfectly well aware that the word frame is used for the Link Layer,
while the word packet is used for the Network Layer. However, when we are talking about IP packets
inside the Link Layer, we will refer to these as frames/packets or packets/frames.
</P>
<A NAME="section2"></A>
<P CLASS="section">
2. How frames traverse the <EM>ebtables</EM> chains
</P>
<DIV CLASS="note">
This section only considers <EM>ebtables</EM>, not
<EM>iptables</EM>.
</DIV>
<P>
First thing to keep in mind is that we are talking about
the Ethernet layer here, so the OSI layer 2 (Data link
layer), or layer 1 (Link layer, Network Access layer) by the TCP/IP Network
Model.
</P>
<P>
A packet destined for the local computer according to the
bridge (which works on the Ethernet layer) isn't
necessarily destined for the local computer according to
the IP layer. That's how routing works (MAC destination is
the router, IP destination is the actual box you want to
communicate with).
</P>
<P>
<IMG SRC="bridge2a.png">
</P>
<P>
<I><B>Figure 2a.</B> General frame traversal scheme</I><BR>
</P>
<P>
</P>
<P>
There are five hooks defined in the Linux bridging code.
The sixth hook (BROUTING) is added by the <EM>ebtables</EM> patch.
</P>
<BR>
<BR>
<IMG SRC="bridge2b.png">
<P>
<I><B>Figure 2b.</B> Ethernet bridging hooks</I><BR>
</P>
</P>
<P>
<P>
The hooks are specific places in the network
code on which software can attach itself to process the
packets/frames passing that place. For example, the kernel module responsible for the <EM>ebtables</EM> FORWARD chain is attached onto the bridge FORWARD hook.
This is done when the module is loaded into the kernel or at bootup.
</P>
<P>
Note that the <EM>ebtables</EM> BROUTING and PREROUTING chains are traversed before the bridging decision, therefore these chains will even see frames that will be
ignored by the bridge. You should take that into account when using this chain. Also note that the chains won't see frames entering on a non-forwarding bridge port.<br>
The bridge's decision for a frame (as seen on Figure 2b) can be one of these:
<ul>
<li>bridge it, if the destination MAC address is on
another side of the bridge;</li>
<li>flood it over all the forwarding bridge ports, if the
position of the box with the destination MAC is unknown
to the bridge;</li>
<li>pass it to the higher protocol code (the IP code),
if the destination MAC address is that of the bridge or of
one of its ports;</li>
<li>ignore it, if the destination MAC address is located
on the same side of the bridge.</li>
</ul>
</P>
<IMG SRC="bridge2c.png">
<P>
<I><B>Figure 2c.</B> Bridging tables (ebtables) traversal
process</I><BR>
</P>
<P>
<EM>Ebtables</EM> has three tables:
<B>filter</B>, <B>nat</B> and <B>broute</B>, as shown in Figure 2c.
</P>
<UL>
<LI>
The <FONT COLOR="#00ffff"><B>broute</B></FONT> table has
the BROUTING chain.
</LI>
<LI>
The <FONT COLOR="#00ffff"><B>filter</B></FONT> table has
the FORWARD, INPUT and OUTPUT chains.
</LI>
<LI>
The <FONT COLOR="#00ffff"><B>nat</B></FONT> table has the
PREROUTING, OUTPUT and POSTROUTING chains.
</LI>
</UL>
<BR>
<DIV CLASS="note">
The filter OUTPUT and nat OUTPUT chains are separated and have
a different usage.
</DIV>
<P>
Figures 2b and 2c give a clear view where the
<EM>ebtables</EM> chains are attached onto the bridge hooks.
</P>
<P>
When an NIC enslaved to a bridge receives a frame, the frame
will first go through the BROUTING chain. In this special
chain you can choose whether to route or bridge frames,
enabling you to make a brouter. The definitions found on
the Internet for what a brouter actually is differ a bit.
The next definition describes the brouting ability using the
BROUTING chain quite well:
</P>
<DIV CLASS="note">
A brouter is a device which
bridges some frames/packets (i.e. forwards based on Link layer
information) and routes other frames/packets (i.e. forwards based
on Network layer information). The bridge/route decision is
based on configuration information.
</DIV>
<P>
A brouter can be used, for example,
to act as a normal router for IP traffic between 2
networks, while bridging specific traffic (NetBEUI, ARP,
whatever) between those networks. The IP routing
table does not use the bridge logical device and the box has
IP addresses assigned to the physical network devices that
also happen to be bridge ports (bridge enslaved NICs).<BR>
The default decision in the BROUTING chain is bridging.
</P>
<P>
Next the frame passes through the PREROUTING chain.
In this chain you can alter the destination MAC address
of frames (DNAT).
If the frame passes this chain, the bridging code will decide where the
frame should be sent. The bridge does this by looking at
the destination MAC address, it doesn't care about the
Network Layer addresses (e.g. IP address).
</P>
<P>
If the bridge decides the frame is destined for the local
computer, the frame will go through the INPUT chain.
In this chain you can filter frames destined for the bridge box.
After traversal of the INPUT chain, the frame will be passed up
to the Network Layer code (e.g. to the IP code).
So, a routed IP packet will go through
the <EM>ebtables</EM> INPUT chain, not through the
<EM>ebtables</EM> FORWARD chain. This is logical.
</P>
<BR>
<BR>
<IMG SRC="bridge2d.png">
<P>
<I><B>Figure 2d.</B> Incoming frames' chain traversal</I><BR>
</P>
<P>
Otherwise the frame should possibly be sent onto another side
of the bridge. If it should, the frame will go through the
FORWARD chain and the POSTROUTING chain. The bridged frames can be
filtered in the FORWARD chain. In the POSTROUTING chain you can alter the MAC
source address (SNAT).
</P>
<BR>
<BR>
<IMG SRC="bridge2e.png">
<P>
<I><B>Figure 2e.</B> Forwarded frames' chain traversal</I><BR>
</P>
<P>
Locally originated frames will, after the bridging decision, traverse
the nat OUTPUT, the filter OUTPUT and the nat POSTROUTING chains.
The nat OUTPUT chain allows to alter the destination
MAC address and the filter OUTPUT chain allows to
filter frames originating from the bridge box. Note that
the nat OUTPUT chain is traversed after the bridging
decision, so this is actually too late. We should change this. The nat
POSTROUTING chain is the same one as described above.
</P>
<BR>
<BR>
<IMG SRC="bridge2f.png">
<P>
<I><B>Figure 2f.</B> Outgoing frames' chain traversal</I><BR>
</P>
<DIV CLASS="note">
It's also possible for routed frames to go
through these three chains when the destination
device is a logical bridge device.
</DIV>
<BR>
<BR>
<A NAME="section3"></A>
<P CLASS="section">
3. A machine used as a bridge and a router (not a brouter)
</P>
<P>
Here is the IP code hooks scheme:
</P>
<IMG SRC="bridge3a.png">
<P>
<I><B>Figure 3a.</B> IP code hooks</I><BR>
</P>
<P>
Here is the iptables packet traversal scheme.
</P>
<BR>
<BR>
<IMG SRC="bridge3b.png">
<P>
<I><B>Figure 3b.</B> Routing tables (iptables) traversal
process</I><BR>
</P>
<P>
Note that the iptables nat OUTPUT chain is situated after the
routing decision. As commented in the previous section,
this is too late for DNAT. This is solved by rerouting the
IP packet if it has been DNAT'ed, before continuing.
</P>
<P>
Figures 3a and 3b give a clear view where the
<EM>iptables</EM> chains are attached onto the IP hooks. When the
br-nf-bds patch is compiled into the kernel, the iptables chains are
also attached onto the hooks of the bridging code. However,
this does not mean that they are no longer attached onto their
standard IP code hooks. For IP packets that get into
contact with the bridging code, the br-nf-bds patch will
decide in which place in the network code the <EM>iptables</EM>
chains are traversed. Obviously, it is guaranteed that no chain is
traversed twice by the same packet. All packets that do not come into
contact with the bridge code traverse the <EM>iptables</EM> chains
in the standard way as seen in Figure 3b.<BR>
The following sections try, among other things,
to explain what the br-nf-bds patch does and why it does it.
</P>
<P>
It's possible to see a single IP packet/frame traverse the
nat PREROUTING, filter INPUT, nat OUTPUT, filter OUTPUT and
nat POSTROUTING <EM>ebtables</EM> chains.<BR>
This can happen when the bridge is also used as a router.
The Ethernet frame(s) containing that IP packet will have
the bridge's destination MAC address, while the destination
IP address is not of the bridge. Including the
<EM>iptables</EM> chains and assuming the br-nf-bds code is
compiled into the kernel, this is how the IP packet runs
through the bridge/router (actually there is more going on,
see <A HREF="#section6">section 6</A>):
</P>
<P>
<IMG SRC="bridge3c.png">
</P>
<P>
<I><B>Figure 3c.</B> Bridge/router routes packet to a
bridge interface (simplistic view)</I><BR>
</P>
<P>
This assumes that the routing decision sends the packet to
a bridge interface. If the routing decision sends the
packet to a physical network card, this is what happens:
</P>
<P>
<IMG SRC="bridge3d.png">
</P>
<P>
<I><B>Figure 3d.</B> Bridge/router routes packet to a
physical interface (simplistic view)</I><BR>
</P>
<P>
Figures 3c and 3d assume the IP packet arrived on a bridge port.
What is obviously "asymmetric" here is that the
<EM>iptables</EM> PREROUTING chain is traversed before the
<EM>ebtables</EM> INPUT chain, however this cannot be
helped without sacrificing other functionality. See the
next section.
</P>
<A NAME="section4"></A>
<P CLASS="section">
4. DNAT'ing bridged packets
</P>
<P>
Take an IP packet received by the bridge. Let's assume we
want to do some IP DNAT on it.
Changing the destination address of the packet (IP address
and MAC address) has to happen before the bridge code
decides what to do with the frame/packet.
</P>
<P>
So, this IP DNAT has to happen very early in the bridge
code. Namely before the bridge code actually does anything.
This is at the same place as where the <EM>ebtables</EM> nat
PREROUTING chain will be traversed (for the same reason).
This should explain the asymmetry encountered in Figures 3c
and 3d.<BR>
One should also be aware of the fact that frames for which the
bridging decision would be the fourth from the above list will
be seen in the PREROUTING chains of <EM>ebtables</EM> and
<EM>iptables</EM>.
</P>
<A NAME="section5"></A>
<P CLASS="section">
5. Chain traversal for bridged IP packets
</P>
<P>
A bridged packet never enters any network code above layer
1 (Link Layer). So, a bridged IP packet/frame will never enter the
IP code.
Therefore all <EM>iptables</EM> chains will be traversed
while the IP packet is in the bridge code. The chain
traversal will look like this:
</P>
<P>
<IMG SRC="bridge5.png">
</P>
<P>
<I><B>Figure 5.</B> Chain traversal for bridged IP
packets</I><BR>
</P>
<A NAME="section6"></A>
<P CLASS="section">
6. Using a bridge port in <EM>iptables</EM> rules
</P>
<P>
The wish to be able to use physical devices belonging to a
bridge (bridge ports) in <EM>iptables</EM> rules is valid.
Knowing the input bridge ports is necessary to prevent
spoofing attacks. Say br0 has ports eth0 and eth1. If
<EM>iptables</EM> rules can only use br0 there's no way of
knowing when a box on the eth0 side changes its source IP
address to that of a box on the eth1 side, except by
looking at the MAC source address (and then still...). With
the br-nf-bds patch you can use eth0 and eth1 in your
<EM>iptables</EM> rules and therefore catch these attempts.
</P>
<P CLASS="case">
6.1. <EM>iptables</EM> wants to use the bridge destination
ports:
</P>
<P>
To make this possible the <EM>iptables</EM> chains have to
be traversed after the bridge code decided where the frame
needs to be sent (eth0, eth1 or both). This has some
impact on the scheme presented in <A HREF=
"#section3">section 3</A> (so, we are looking at routed
traffic here, entering the box on a bridge port). It actually
looks like this (in the case of Figure 3c):
</P>
<P>
<IMG SRC="bridge6a.png">
</P>
<P>
<I><B>Figure 6a.</B> Chain traversal when routing and br-nf-bds
is compiled into the kernel</I><BR>
</P>
<DIV CLASS="note">
All chains are now traversed while in the bridge code.<BR>
This is the work of the br-nf-bds patch. Obviously this does not
mean that the routed IP packets never enter the IP code. They
just don't pass any <EM>iptables</EM> chains while in the IP code.
</DIV>
<P>
If one does not compile the br-nf-bds code into the kernel, the
chains will be traversed as shown below. However, then one
can only use br0, not eth0/eth1 to filter.
</P>
<P>
<IMG SRC="bridge6b.png">
</P>
<P>
<I><B>Figure 6b.</B> Chain traversal when routing and br-nf-bds
code is not compiled into the kernel</I><BR>
</P>
<P>
Notice that the <EM>iptables</EM> PREROUTING chain is now in
the natural position in the chain list and too far to be able
to change the bridging decision. More precise: the <EM>iptables</EM>
PREROUTING chain is now traversed when the packet is already
in the IP code.
</P>
<P CLASS="case">
6.2. IP DNAT for locally generated packets (so in the
<EM>iptables</EM> nat OUTPUT chain):
</P>
<P>
The normal way locally generated packets would go through
the chains looks like this:
</P>
<P>
<IMG SRC="bridge6c.png">
</P>
<P>
<I><B>Figure 6c.</B> The normal way for locally generated
packets</I><BR>
</P>
<P>
From <A HREF="#section6">section 6.1</A> we know that this
actually looks like this (due to the br-nf-bds code):
</P>
<P>
<IMG SRC="bridge6d.png">
</P>
<P>
<I><B>Figure 6d.</B> The actual way for locally generated
packets</I><BR>
</P>
<P>
Note that the <EM>iptables</EM> nat OUTPUT chain is traversed while the
packet is in the IP code and the <EM>iptables</EM> filter OUTPUT chain
is traversed when the packet has passed the bridging decision.
This makes it possible to do DNAT to another device in the
nat OUTPUT chain and lets us use the bridge ports in the
filter OUTPUT chain.
</P>
<A NAME="section7"></A>
<P CLASS="section">
7. Two possible ways for frames/packets to pass through the
<EM>iptables</EM> PREROUTING, FORWARD and POSTROUTING
chains
</P>
<P>
With the br-nf-bds patch there are 2 ways a frame/packet can
pass through the 3 given <EM>iptables</EM> chains. The
first way is when the frame is bridged, so the
<EM>iptables</EM> chains are called by the bridge code. The
second way is when the packet is routed. So special care
has to be taken to distinguish between those two,
especially in the <EM>iptables</EM> FORWARD chain. Here's
an example of strange things to look out for:
</P>
<P>
Consider the following situation
</P>
<P>
<IMG SRC="bridge7a.png">
</P>
<P>
<I><B>Figure 7a.</B> Very basic setup.</I><BR>
</P>
<P>
The default gateway for 172.16.1.2 and
172.16.1.4 is 172.16.1.1. 172.16.1.1 is the bridge
interface br0 with ports eth1 and eth2.
</P>
<P CLASS="case">
More details:
</P>
<P>
The idea is that traffic between 172.16.1.4 and 172.16.1.2 is
bridged, while the rest is routed, using masquerading.
</P>
<P>
<IMG SRC="bridge7b.png">
</P>
<P>
<I><B>Figure 7b.</B> Traffic flow for the example setup.</I><BR>
</P>
<P>
Here's a possible scheme to use at bootup for the bridge/router:
</P>
<PRE>
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -d 172.16.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.1.0/24 -j MASQUERADE
brctl addbr br0
brctl stp br0 off
brctl addif br0 eth1
brctl addif br0 eth2
ifconfig eth1 0 0.0.0.0
ifconfig eth2 0 0.0.0.0
ifconfig br0 172.16.1.1 netmask 255.255.255.0 up
echo '1' > /proc/sys/net/ipv4/ip_forward
</PRE>
<P>
The catch is in the first line. Because the
<EM>iptables</EM> code gets executed for both bridged
packets and routed packets we need to make a distinction
between the two. We don't really want the bridged frames/packets
to be masqueraded. If we omit the first line then
everything will work too, but things will happen
differently. Let's say 172.16.1.2 pings 172.16.1.4. The
bridge receives the ping request and will transmit it
through its eth1 port after first masquerading the IP
address. So the packet's source IP address will now be
172.16.1.1 and 172.16.1.4 will respond to the bridge.
Masquerading will change the IP destination of this
response from 172.16.1.1 to 172.16.1.4. Everything works
fine. But it's better not to have this behaviour. Thus, we
use the first line to avoid this. Note that
if we would want to filter the connections to and from the
Internet, we would certainly need the first line so we don't
filter the local connections as well.
</P>
<A NAME="section8"></A>
<P CLASS="section">
8. IP DNAT in the <EM>iptables</EM> PREROUTING chain on
frames/packets entering on a bridge port
</P>
<P>
Through some groovy play it is assured that (see
/net/bridge/br_netfilter.c) DNAT'ed packets that after
DNAT'ing have the same output device as the input device
they came on (the logical bridge device which we like to
call br0) will go through the <EM>ebtables</EM> FORWARD
chain, not through the <EM>ebtables</EM> INPUT/OUTPUT chains. All
other DNAT'ed packets will be purely routed, so won't go
through the <EM>ebtables</EM> FORWARD chain, will go through
the <EM>ebtables</EM> INPUT chain and might go through the
<EM>ebtables</EM> OUTPUT chain.<BR>
</P>
<A NAME="section9"></A>
<P CLASS="section">
9. Using the MAC module extension for <EM>iptables</EM>
</P>
<P>
The side effect explained here occurs when the br-nf-bds code
is compiled in the kernel, the IP packet is routed and the
out device for that packet is a logical bridge device. The
side effect is encountered when filtering on the MAC source
in the <EM>iptables</EM> FORWARD chains. As should be clear
from earlier sections, the traversal of the
<EM>iptables</EM> FORWARD chains is postponed until the
packet is in the bridge code. This is done so we can
filter on the bridge port out device. This has a side
effect on the MAC source address, because the IP code will
have changed the MAC source address to the MAC address of
the bridge device. It is therefore impossible, in the
<EM>iptables</EM> FORWARD chains, to filter on the MAC
source address of the computer sending the packet in
question to the bridge/router. If you really need to filter
on this MAC source address, you should do it in the nat
PREROUTING chain. Agreed, very ugly, but making it possible
to filter on the real MAC source address in the FORWARD
chains would involve a very dirty hack and is probably not
worth it. This of course makes the anti-spoofing remark of
<A HREF="#section5">section 6</A> funny. If I'm [BDS]
pressured enough I could hack something up to make this
unpleasant side effect go away.
</P>
<A NAME="section10"></A>
<P CLASS="section">
10. Using the <EM>iptables</EM> physdev match module for kernel 2.5
</P>
The 2.5 standard kernel contains an <EM>iptables</EM> match module
called <EM>physdev</EM> which has to be used to match the bridge's
physical in and out ports. Its usage is simple:
<PRE>iptables -m physdev --physdev-in <bridge-port></PRE>
and
<PRE>iptables -m physdev --physdev-out <bridge-port></PRE>
<HR>
<PRE>
Released under the GNU Free Documentation License.
Copyright (c) 2002 Bart De Schuymer <bart.de.schuymer@pandora.be>,
Nick Fedchik <nick@fedchik.org.ua>.
</PRE>
<BR>
<BR>
<BR>
<SMALL>Permission is granted to copy, distribute and/or
modify this document under the terms of the GNU Free
Documentation License, Version 1.1 or any later version
published by the Free Software Foundation, with no Invariant Sections,
with no Front-Cover Texts, and with no Back-Cover Texts. For a copy of the
license, see <A HREF=
"http://www.gnu.org/licenses/fdl.txt">"GNU Free Documentation License"</A>.</SMALL> <BR>
<BR>
<P>
Last updated September 27, 2002.
</P>
</BODY>
</HTML>
|
