All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Cockburn <jcockburn@bloxx.com>
To: Pascal Hambourg <pascal@plouf.fr.eu.org>
Cc: "netfilter@vger.kernel.org" <netfilter@vger.kernel.org>
Subject: RE: Iptables: Matching packets leaving a bridged interface
Date: Wed, 25 Jun 2014 10:49:52 +0000	[thread overview]
Message-ID: <D1310F2F383A5D4D8D7944C4FB42CFA84CA24A@BLX-EX01.alba.local> (raw)
In-Reply-To: <53AA9D26.9000505@plouf.fr.eu.org>

Pascal!

Thanks for getting back to me.  Very helpful information!

Pascal Hambourg wrote:
> Because the packet is not bridged, as eth2 is not part of the bridge. So  it won't follow the FORWARD bridging path but the FORWARD IP routing path.
>
> See the packet flow diagram in <http://en.wikipedia.org/wiki/Netfilter>.

I think I follow... So based on the diagram, my packet is initially hitting "bridge check", heading along the green "network layer" path, hitting "routing decision", and dropping down into the blue "link layer" path.  Hence, until it gets to ebtables -> nat -> output, it's not gone anywhere near the bridging mechanism, so has never has PHYSOUT set.

Couple of follow-up question then!

1: Do you know if by the time it reaches ebtables -> filter -> output that the packet will have a PHYSOUT (or equivalent) set?

2: Will I be able to differentiate between packets for eth0 and eth1 (when the bridge doesn't know which specific interface it should send it on).

Now I need to complicate my original scenario...say I want to drop packets the originate from eth2 (the non-bridged interface) and will egress on eth0.

3: I'm guessing that by the time the packet hits ebtables -> filter -> output, that it will have lost its IN/PHYSIN?

4: If that is the case, would something like this work:
      - In iptables -> filter: -A FORWARD -i eth2 -o br0 -j MARK --set-mark 1234
      - In ebtable -> filter: -A OUTPUT -physdev-out eth0 --m mark --mark 1234 -j DROP

Jamie

-----Original Message-----
From: Pascal Hambourg [mailto:pascal@plouf.fr.eu.org] 
Sent: 25 June 2014 10:58
To: Jamie Cockburn
Cc: netfilter@vger.kernel.org
Subject: Re: Iptables: Matching packets leaving a bridged interface

Hello,

Jamie Cockburn a écrit :
> 
> Given a setup with eth0 and eth1 in a bridge br0 and a third interface eth2.
> 
> In this scenario, lets say I want TCP port 80 traffic to be dropped if it is going to the network attached to eth0, but allow it to eth1.
> 
> I am therefore trying to reliably match packets that go out over the specific interface eth0.
> 
> If I add the following iptables rule in the filter table:
> 
>     -A FORWARD -o br0 --physdev-out eth0 -j LOG
> 
> Given a packet that originates from eth1 (the other half of the bridge), then the rule matches just fine, logging:
> 
>     ... IN=br0 OUT=br0 PHYSIN=eth2 PHYSOUT=eth1 ...
> 
> However if the packet origniates from eth2, then the rule no longer matches.
Report this message as spam http://joey.alba.local/quarantine/notifications/reportspam/message/1813852/check/9da66caf713bf11249ee4bc6db23fa2f



  reply	other threads:[~2014-06-25 10:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25  8:03 Iptables: Matching packets leaving a bridged interface Jamie Cockburn
2014-06-25  9:57 ` Pascal Hambourg
2014-06-25 10:49   ` Jamie Cockburn [this message]
2014-06-25 11:03     ` Pascal Hambourg
2014-06-26  8:27       ` Jamie Cockburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D1310F2F383A5D4D8D7944C4FB42CFA84CA24A@BLX-EX01.alba.local \
    --to=jcockburn@bloxx.com \
    --cc=netfilter@vger.kernel.org \
    --cc=pascal@plouf.fr.eu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.