PPPoE on a bridge, nat sees bridge as incoming interface

PPPoE on a bridge, nat sees bridge as incoming interface

[Georgi Georgiev]

Hi all,


I am having trouble understaning how bridging and iptables fit together.
The situation that bugs me is: if I do a PPPoE connection over a bridge
with a single physical port, my nat table will see any incoming packet
as coming from the bridge interface, and not the ppp interface. Why?

The issue I have is similar to what this poster
http://marc.info/?l=netfilter&m=120451146916327 but there were no
responses.  If it's something basic, please at least give tell me what
keywords to use as I am having trouble finding anything.

The setup to reproduce this is simple:

modem <-> eth0 <-> pppd (ppp0)

All chains have a single -j LOG rule.
Kernel is 2.6.24.3 with no patches.

I ping myself from a remote host and I get this:

t=mangle c=PREROUTING  IN=ppp0 OUT= MAC= SRC=<remote_IP> DST=<local_IP>
t=nat    c=PREROUTING  IN=ppp0 OUT= MAC= SRC=<remote_IP> DST=<local_IP>
t=mangle c=INPUT       IN=ppp0 OUT= MAC= SRC=<remote_IP> DST=<local_IP>
t=filter c=INPUT       IN=ppp0 OUT= MAC= SRC=<remote_IP> DST=<local_IP>
t=mangle c=OUTPUT      IN=     OUT=ppp0  SRC=<local_IP> DST=<remote_IP>
t=filter c=OUTPUT      IN=     OUT=ppp0  SRC=<local_IP> DST=<remote_IP>
t=mangle c=POSTROUTING IN=     OUT=ppp0  SRC=<local_IP> DST=<remote_IP>

nat sees the ping as coming from ppp0. Good.

Now, I add a bridge and connect eth0 to it.
# brctl add br0
# brctl addif br0 eth0

I connect with pppd in the same way as before (through eth0), ping myself, and
I get what looks like identical output. (Skipping the output)

Now I connect again, but this time pppd uses br0 to get to the internet
and the output becomes:

t=mangle c=PREROUTING  IN=br0 OUT=  PHYSIN=eth0 MAC=<eth0_mac>:<router_mac>:88:64 SRC=<remote_IP> DST=<local_IP>
t=nat    c=PREROUTING  IN=br0 OUT=  PHYSIN=eth0 MAC=<eth0_mac>:<router_mac>:88:64 SRC=<remote_IP> DST=<local_IP>
t=mangle c=INPUT       IN=ppp0 OUT= PHYSIN=eth0 MAC= SRC=<remote_IP> DST=<local_IP>
t=filter c=INPUT       IN=ppp0 OUT= PHYSIN=eth0 MAC= SRC=<remote_IP> DST=<local_IP>
t=mangle c=OUTPUT      IN= OUT=ppp0 SRC=<local_IP> DST=<remote_IP>
t=filter c=OUTPUT      IN= OUT=ppp0 SRC=<local_IP> DST=<remote_IP>
t=mangle c=POSTROUTING IN= OUT=ppp0 SRC=<local_IP> DST=<remote_IP>

As you can see, the nat table sees the incoming packet as coming from
the bridge itself and from the ppp interface. Why is that?

The implication of this is that I cannot choose my DNAT rules based on
the incoming (ppp) interface (which  I can easily do if I don't connect
pppd to a bridge).

-- 
()   Georgi Georgiev   () I am having FUN... I wonder if it's NET    ()
()    chutz@gg3.net    () FUN or GROSS FUN?                          ()
() http://www.gg3.net/ ()                                            ()

Re: PPPoE on a bridge, nat sees bridge as incoming interface

[Grant Taylor]

On 3/6/2008 11:22 AM, Georgi Georgiev wrote:
> I am having trouble understaning how bridging and iptables fit 
> together. The situation that bugs me is: if I do a PPPoE connection 
> over a bridge with a single physical port, my nat table will see any 
> incoming packet as coming from the bridge interface, and not the ppp 
> interface. Why?

With out going any further in your email (I've read the rest but IMHO 
this takes precedence).  Is your kernel configured to have IPTables see 
your bridged traffic?  Is "CONFIG_BRIDGE_NETFILTER" enabled in your 
kernel?  Here is a quote from help from menuconfig about Bridge Netfilter:

"Enabling this option will let arptables resp. iptables see bridged ARP 
resp. IP traffic. If you want a bridging firewall, you probably want 
this option enabled.  Enabling or disabling this option doesn't enable 
or disable ebtables."

If you turn this off your bridging will be a purely layer 2 operation 
that IPTables (and ARPTables) will be completely oblivious of.  If you 
wish to filter bridged traffic you will have to use EBTables. 
Incidentally I have had better luck turning this off (unless I had to 
have IPTables filtering of bridged traffic) and using EBTables to filter 
bridged traffic.  I consider this to be use layer 3 filtering (IPTables 
and ARPTables) for layer 3 traffic and use layer 2 filtering (EBTables) 
for layer 2 traffic.  In other words don't use layer 3 filtering for 
layer 3 and 2 traffic which is what this does.  Granted you can use 
IPTables to filter layer 2 traffic, however you have to be aware of the 
ramifications and account for them in your firewall and logic in your head.



Grant. . . .

Re: PPPoE on a bridge, nat sees bridge as incoming interface

[Jan Engelhardt]

On Mar 6 2008 16:01, Grant Taylor wrote:
> On 3/6/2008 11:22 AM, Georgi Georgiev wrote:
>> I am having trouble understaning how bridging and iptables fit together. The
>> situation that bugs me is: if I do a PPPoE connection over a bridge with a
>> single physical port, my nat table will see any incoming packet as coming
>> from the bridge interface, and not the ppp interface. Why?

Without having it seen in practice, I am convinced that pppoe packets
being sent into a bridge or received from it will only ever appear in
ebtables and not iptables nor arptables, logically because they
are pppoe and not ipv4 nor arp, respectively.
Hence it will not show up in the ip_tables nat table either.

Re: PPPoE on a bridge, nat sees bridge as incoming interface

[Pascal Hambourg]

Hello,

Georgi Georgiev wrote :
> 
> I am having trouble understaning how bridging and iptables fit together.
> The situation that bugs me is: if I do a PPPoE connection over a bridge
> with a single physical port, my nat table will see any incoming packet
> as coming from the bridge interface, and not the ppp interface. Why?

I guess you have a kernel 2.6.22 or above.

 From ChangeLog-2.6.22 :
     [NETFILTER]: bridge-nf: filter bridged IPv4/IPv6 encapsulated in
     pppoe traffic

     The attached patch by Michael Milner adds support for using iptables
     and ip6tables on bridged traffic encapsulated in pppoe frames,
     similar to what's already supported for vlan.

Setting the net.bridge.bridge-nf-filter-pppoe-tagged sysctl 
(/proc/sys/net/bridge/bridge-nf-filter-pppoe-tagged) to 0 should disable it.

 From <kernelsourcedir>/Documentation/networking/ip-sysctl.txt :

bridge-nf-filter-pppoe-tagged - BOOLEAN
     1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables.
     0 : disable this.
     Default: 1

Re: PPPoE on a bridge, nat sees bridge as incoming interface

[Georgi Georgiev]

maillog: 06/03/2008-23:36:53(+0100): Pascal Hambourg types
> Hello,
>
> Georgi Georgiev wrote :
>> I am having trouble understaning how bridging and iptables fit together.
>> The situation that bugs me is: if I do a PPPoE connection over a bridge
>> with a single physical port, my nat table will see any incoming packet
>> as coming from the bridge interface, and not the ppp interface. Why?
>
> I guess you have a kernel 2.6.22 or above.
>
> From ChangeLog-2.6.22 :
>     [NETFILTER]: bridge-nf: filter bridged IPv4/IPv6 encapsulated in
>     pppoe traffic
>
>     The attached patch by Michael Milner adds support for using iptables
>     and ip6tables on bridged traffic encapsulated in pppoe frames,
>     similar to what's already supported for vlan.
>
> Setting the net.bridge.bridge-nf-filter-pppoe-tagged sysctl 
> (/proc/sys/net/bridge/bridge-nf-filter-pppoe-tagged) to 0 should disable 
> it.
>
> From <kernelsourcedir>/Documentation/networking/ip-sysctl.txt :
>
> bridge-nf-filter-pppoe-tagged - BOOLEAN
>     1 : pass bridged pppoe-tagged IP/IPv6 traffic to {ip,ip6}tables.
>     0 : disable this.
>     Default: 1

The above did the trick with immediate effect. Thanks!

-- 
/\   Georgi Georgiev   /\ Calling you stupid is an insult to stupid  /\
\/    chutz@gg3.net    \/ people! -- Wanda, "A Fish Called Wanda"    \/
/\  +81(90)2877-8845   /\                                            /\

Re: PPPoE on a bridge, nat sees bridge as incoming interface

[Georgi Georgiev]

maillog: 06/03/2008-16:01:35(-0600): Grant Taylor types
> On 3/6/2008 11:22 AM, Georgi Georgiev wrote:
>> I am having trouble understaning how bridging and iptables fit together. 
>> The situation that bugs me is: if I do a PPPoE connection over a bridge 
>> with a single physical port, my nat table will see any incoming packet as 
>> coming from the bridge interface, and not the ppp interface. Why?
>
> With out going any further in your email (I've read the rest but IMHO this 
> takes precedence).  Is your kernel configured to have IPTables see your 
> bridged traffic?  Is "CONFIG_BRIDGE_NETFILTER" enabled in your kernel?  
> Here is a quote from help from menuconfig about Bridge Netfilter:
>
> "Enabling this option will let arptables resp. iptables see bridged ARP 
> resp. IP traffic. If you want a bridging firewall, you probably want this 
> option enabled.  Enabling or disabling this option doesn't enable or 
> disable ebtables."
>
> If you turn this off your bridging will be a purely layer 2 operation that 
> IPTables (and ARPTables) will be completely oblivious of.  If you wish to 
> filter bridged traffic you will have to use EBTables. Incidentally I have 
> had better luck turning this off (unless I had to have IPTables filtering 
> of bridged traffic) and using EBTables to filter bridged traffic.  I 
> consider this to be use layer 3 filtering (IPTables and ARPTables) for 
> layer 3 traffic and use layer 2 filtering (EBTables) for layer 2 traffic.  
> In other words don't use layer 3 filtering for layer 3 and 2 traffic which 
> is what this does.  Granted you can use IPTables to filter layer 2 traffic, 
> however you have to be aware of the ramifications and account for them in 
> your firewall and logic in your head.

I agree. I thought the bridge was supposed to behave like a switching
hub. And it probably does, but I had misconfigured it.

I have applided the sysctl fix from the other post in the thread for
now. I'll test your suggestion when I get home.

-- 
(    Georgi Georgiev   (  Q: Why did the lone ranger kill Tonto? A:  (
 )    chutz@gg3.net     ) He found out what "kimosabe" really means.  )
(  http://www.gg3.net/ (                                             (

Re: PPPoE on a bridge, nat sees bridge as incoming interface

[Pascal Hambourg]

Georgi Georgiev wrote :
> 
> I thought the bridge was supposed to behave like a switching
> hub. And it probably does, but I had misconfigured it.

Yes it does. Originally, i.e. in the vanilla 2.4 kernel, this is exactly 
and only what it does. Then people thought it would be cool to add some 
filtering capabilities so you could build a filtering bridge. So here 
came ebtables. But it had some limitations, so people thougt it would be 
cool that netfilter/iptables could be used on bridged IP packets, 
although it would be an ugly hack. So here came bridge-nf. Then people 
thought it would be cool that netfilter/iptables could also be used on 
IP packets encapsulated in bridged VLAN tagged frames, and finally in 
bridged PPPoE frames. So far so good. But IMHO the problem is that those 
features should have been disabled by default so the original behaviour 
expected by most people would have been preserved.

Re: PPPoE on a bridge, nat sees bridge as incoming interface

[Grant Taylor]

On 3/6/2008 7:13 PM, Pascal Hambourg wrote:
> But IMHO the problem is that those features should have been disabled 
> by default so the original behaviour expected by most people would 
> have been preserved.

I'll second that.



Grant. . . .

[SOLVED] PPPoE on a bridge, nat sees bridge as incoming interface

[Georgi Georgiev]

My problem has been solved for a week now. Here is the summary.

Problem: If a PPPoE connection is initialized over a bridge the nat
table will see any incoming IP packet as coming from the bridge
interface, and not the ppp interface.

Solution 1: Set the following sysctl key to 0
net.bridge.bridge-nf-filter-pppoe-tagged

Warning: If adding this to /etc/sysctl.conf (or equivalent), make sure
that the bridge module gets loaded *before* sysctl is applied.

Solution 2: Compile the kernel without CONFIG_BRIDGE_NETFILTER.

Both of these worked for me. I'm sticking with number two.

-- 
()   Georgi Georgiev   () If you don't care where you are, then you  ()
()    chutz@gg3.net    () ain't lost.                                ()
() http://www.gg3.net/ ()                                            ()

Re: [SOLVED] PPPoE on a bridge, nat sees bridge as incoming interface

[Jan Engelhardt]

On Mar 11 2008 20:08, Georgi Georgiev wrote:
>
>My problem has been solved for a week now. Here is the summary.
>
>Problem: If a PPPoE connection is initialized over a bridge the nat
>table will see any incoming IP packet as coming from the bridge
>interface, and not the ppp interface.

Solution 3: iptables -m physdev --physdev-in ppp0 -i br0
            ebtables --logical-in ppp0 -i br0

>Solution 1: Set the following sysctl key to 0
>net.bridge.bridge-nf-filter-pppoe-tagged
>
>Warning: If adding this to /etc/sysctl.conf (or equivalent), make sure
>that the bridge module gets loaded *before* sysctl is applied.
>
>Solution 2: Compile the kernel without CONFIG_BRIDGE_NETFILTER.
>
>Both of these worked for me. I'm sticking with number two.

Re: [SOLVED] PPPoE on a bridge, nat sees bridge as incoming interface

[Pascal Hambourg]

Jan Engelhardt a écrit :
>>
>>Problem: If a PPPoE connection is initialized over a bridge the nat
>>table will see any incoming IP packet as coming from the bridge
>>interface, and not the ppp interface.
> 
> Solution 3: iptables -m physdev --physdev-in ppp0 -i br0
>             ebtables --logical-in ppp0 -i br0

Could you elaborate, please ?

--physdev-in expects a bridge port, which ppp0 is not.
--logical-in expects a bridge interface, which ppp0 is not.
-i in ebtables expects a bridge port, which br0 is not.
Also, the targets are missing.

Re: [SOLVED] PPPoE on a bridge, nat sees bridge as incoming interface

[Jan Engelhardt]

On Mar 11 2008 15:32, Pascal Hambourg wrote:
> Jan Engelhardt a écrit :
>> >
>> >Problem: If a PPPoE connection is initialized over a bridge the nat
>> >table will see any incoming IP packet as coming from the bridge
>> >interface, and not the ppp interface.
>> 
>> Solution 3: iptables -m physdev --physdev-in ppp0 -i br0
>>             ebtables --logical-in ppp0 -i br0
>
> Could you elaborate, please ?

Oh, I misread it. ppp0 on br0 hm... like I said before, the
ip_tables nat table should never even see PPP, only ebtables nat may,
and it can be matched with (--logical-in br0 -i/-o ppp0 -p 0x880b),
does not it?


> Also, the targets are missing.

The target is for you to decide.