All of lore.kernel.org
 help / color / mirror / Atom feed
* [Bridge] Clarification regarding device matches in bridge-netfilter
@ 2006-12-05 12:37 Tino Keitel
  2006-12-05 17:13 ` Tino Keitel
  2006-12-05 17:19 ` Stephen Hemminger
  0 siblings, 2 replies; 3+ messages in thread
From: Tino Keitel @ 2006-12-05 12:37 UTC (permalink / raw)
  To: bridge

Hi folks,

in 2.4 kernels, device matching for bridged packets was done with
iptables -i/-o. Since 2.6, I was used to use -m physdev here.

In 2.6.18, This seems to be more complicated. At least the filter/INPUT
chain now doesn't match with -m physdev --physdev-in anymore, but
FORWARD and OUTPUT does. I also read the note that -m phydev is now
deprecated for non-bridged traffic.

Does this mean that

1. I have to use the physdev match for bridged traffic, e.g. FORWARD,
   POSTROUTING, PREROUTING

2. I have to use iptables -i in the INPUT chain and on PREROUTING

3. I have to use the physdev match in the OUTPUT chain

4. I have to distinguish between bridged and locally processed or
   routed traffic in PREROUTING, since bridged traffic needs -m
   physdev, whereas the other traffic need -i

5. until now, outgoing traffic is always matched with -m physdev, but
   this will change in the future. If the change is made, I'll have to
   distinguish in the same way as for incoming traffic

Regards,
Tino

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bridge] Clarification regarding device matches in bridge-netfilter
  2006-12-05 12:37 [Bridge] Clarification regarding device matches in bridge-netfilter Tino Keitel
@ 2006-12-05 17:13 ` Tino Keitel
  2006-12-05 17:19 ` Stephen Hemminger
  1 sibling, 0 replies; 3+ messages in thread
From: Tino Keitel @ 2006-12-05 17:13 UTC (permalink / raw)
  To: bridge

On Tue, Dec 05, 2006 at 13:37:29 +0100, Tino Keitel wrote:
> Hi folks,
> 
> in 2.4 kernels, device matching for bridged packets was done with
> iptables -i/-o. Since 2.6, I was used to use -m physdev here.
> 
> In 2.6.18, This seems to be more complicated. At least the filter/INPUT
> chain now doesn't match with -m physdev --physdev-in anymore, but
> FORWARD and OUTPUT does. I also read the note that -m phydev is now
> deprecated for non-bridged traffic.
> 
> Does this mean that
> 
> 1. I have to use the physdev match for bridged traffic, e.g. FORWARD,
>    POSTROUTING, PREROUTING
> 
> 2. I have to use iptables -i in the INPUT chain and on PREROUTING
> 
> 3. I have to use the physdev match in the OUTPUT chain
> 
> 4. I have to distinguish between bridged and locally processed or
>    routed traffic in PREROUTING, since bridged traffic needs -m
>    physdev, whereas the other traffic need -i
> 
> 5. until now, outgoing traffic is always matched with -m physdev, but
>    this will change in the future. If the change is made, I'll have to
>    distinguish in the same way as for incoming traffic

Hi,

I'm quite puzzled.

A packet that is redirected from the bridge to be processed locally
isn't always matched with -i or -m physdev.

The bridge has 2 interfaces. For one interface, I have to use -i, for
the other interface, I have to use -m physdev. See the iptables output below.
As you can see, the second line with -m physdev matches.

0  0        tcp -- eth0+ * 0.0.0.0/0 0.0.0.0/0
1 60 ACCEPT tcp -- br0   * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 PHYSDEV match --physdev-in eth0+

The next lines are for a packet that comes in at the other bridge
interface:

1 60        tcp -- eth1+ * 0.0.0.0/0 0.0.0.0/0
0  0 ACCEPT tcp -- br0   * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443 PHYSDEV match --physdev-in eth1+

As you can see, the -i eth1+ matches, -m physdev does not.

All rules are in a user defined chain that is referenced in the INPUT
chain. The kernel is still 2.6.18. Is there something wrong? If not,
how do I know if I have to use -i or -m physdev, without trial and
error?

Regards,
Tino

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Bridge] Clarification regarding device matches in bridge-netfilter
  2006-12-05 12:37 [Bridge] Clarification regarding device matches in bridge-netfilter Tino Keitel
  2006-12-05 17:13 ` Tino Keitel
@ 2006-12-05 17:19 ` Stephen Hemminger
  1 sibling, 0 replies; 3+ messages in thread
From: Stephen Hemminger @ 2006-12-05 17:19 UTC (permalink / raw)
  To: Tino Keitel; +Cc: bridge

On Tue, 5 Dec 2006 13:37:29 +0100
Tino Keitel <tino.keitel@innominate.com> wrote:

> Hi folks,
> 
> in 2.4 kernels, device matching for bridged packets was done with
> iptables -i/-o. Since 2.6, I was used to use -m physdev here.
> 
> In 2.6.18, This seems to be more complicated. At least the filter/INPUT
> chain now doesn't match with -m physdev --physdev-in anymore, but
> FORWARD and OUTPUT does. I also read the note that -m phydev is now
> deprecated for non-bridged traffic.
> 
> Does this mean that
> 
> 1. I have to use the physdev match for bridged traffic, e.g. FORWARD,
>    POSTROUTING, PREROUTING
> 
> 2. I have to use iptables -i in the INPUT chain and on PREROUTING
> 
> 3. I have to use the physdev match in the OUTPUT chain
> 
> 4. I have to distinguish between bridged and locally processed or
>    routed traffic in PREROUTING, since bridged traffic needs -m
>    physdev, whereas the other traffic need -i
> 
> 5. until now, outgoing traffic is always matched with -m physdev, but
>    this will change in the future. If the change is made, I'll have to
>    distinguish in the same way as for incoming traffic
> 
> Regards,
> Tino
> _______________________________________________
> Bridge mailing list
> Bridge@lists.osdl.org
> https://lists.osdl.org/mailman/listinfo/bridge
> 

Post netfilter questions to 
	netfilter@lists.netfilter.org
-- 
Stephen Hemminger <shemminger@osdl.org>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-12-05 17:19 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-12-05 12:37 [Bridge] Clarification regarding device matches in bridge-netfilter Tino Keitel
2006-12-05 17:13 ` Tino Keitel
2006-12-05 17:19 ` Stephen Hemminger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.