Bug 13079 - bridge not working when MASQUERADE is active
Summary: bridge not working when MASQUERADE is active
Status: CLOSED DOCUMENTED
Alias: None
Product: Networking
Classification: Unclassified
Component: Netfilter/Iptables (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: networking_netfilter-iptables@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-04-13 07:02 UTC by Sergey
Modified: 2012-05-30 16:10 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.27
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Sergey 2009-04-13 07:02:22 UTC
Hello.

2.6.27-ovz-smp-alt3 #1 SMP Tue Apr 7 17:06:33 UTC 2009 x86_64 GNU/Linux

configuration:

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE

# brctl show
bridge name     bridge id               STP enabled     interfaces
bridge1         8000.0015172652e5       yes             eth0.22
                                                        eth6.22

eth0.22 and eth6.22 both without IP addresses. If ethernet segments which connected via bridge1 used, for example, 192.168.1.0/24, bridge is not work because IP-addressess MASQUERADEd between eth0.22 and eth6.22. But it starts to work, if any IP-address from the 192.168.1.0/24 set on bridge1. I believe that IP-operation should not be made for traffic between bridged interfaces.
Comment 1 Sergey 2009-04-13 15:11:58 UTC
Some about workarounds.

This is resolving the problem for 192.168.1.0/24:
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE

But this is not:
iptables -t nat -A POSTROUTING -o eth0.22 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth6.22 -j ACCEPT
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -j MASQUERADE

Is this a problem with 802.1q also ? eth0.22 and eth6.22 are 802.1q interfaces
Comment 2 Sergey 2009-04-13 16:03:06 UTC
And
iptables -t nat -A POSTROUTING -o eth0.11 -s 192.168.0.0/16 -j MASQUERADE
can be used as workaround too, if outgoing NAT interface(s) can be specified.
Comment 3 Patrick McHardy 2009-04-14 11:20:00 UTC
I agree that this shouldn't be done by default, it has unfortunately been the default since the introduction of bridge netfilter and we can't change it now, at least not without a long warning period.
Comment 4 Sergey 2009-04-16 06:36:54 UTC
(In reply to comment #3)

leave the bug as memo ? Or close it ?

Note You need to log in before you can comment on or make changes to this bug.