Re: Veth problems with bridge

Re: Veth problems with bridge

[Patrick McHardy]

Bernhard Miklautz wrote:
> [...]
> I also tried the whole setup without using veth; the IP directly bound
> to br0, as well as without the bridge at all. No problems with that.
> So there might be some problems with veth?

Does "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables" fix it?

Re: Veth problems with bridge

[Bernhard Miklautz]

Hi Patrick,

Patrick McHardy wrote:
> Bernhard Miklautz wrote:
>> [...]
>> I also tried the whole setup without using veth; the IP directly bound
>> to br0, as well as without the bridge at all. No problems with that.
>> So there might be some problems with veth?
> 
> Does "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables" fix it?

On my hardware machine this seems to fix the problem :). But why does
bridge-nf-call-iptables influent source nat on an other interface? -
Shouldn't the source address always be translated when an output
interface is set (iptables -A POSTROUTING -o eth3 -t nat -j MASQUERADE)?

Thanks for you quick help.

Best regards,
Bernhard

Re: Veth problems with bridge

[Patrick McHardy]

Bernhard Miklautz wrote:
> Hi Patrick,
> 
> Patrick McHardy wrote:
>> Bernhard Miklautz wrote:
>>> [...]
>>> I also tried the whole setup without using veth; the IP directly bound
>>> to br0, as well as without the bridge at all. No problems with that.
>>> So there might be some problems with veth?
>> Does "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables" fix it?
> 
> On my hardware machine this seems to fix the problem :). But why does
> bridge-nf-call-iptables influent source nat on an other interface? -
> Shouldn't the source address always be translated when an output
> interface is set (iptables -A POSTROUTING -o eth3 -t nat -j MASQUERADE)?


The bridging code passes packets through IPv4 netfilter and
connection tracking, so when they hit your MASQUERADE rule,
the NAT mappings have already been set up.

Its a really bad default, but I feel uneasy changing it since
I'm sure some people are relying on it.

Re: Veth problems with bridge

[Bernhard Miklautz]

Hi Patrick,

Patrick McHardy wrote:
>>>> I also tried the whole setup without using veth; the IP directly bound
>>>> to br0, as well as without the bridge at all. No problems with that.
>>>> So there might be some problems with veth?
>>> Does "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables" fix it?
>>
>> On my hardware machine this seems to fix the problem :). But why does
>> bridge-nf-call-iptables influent source nat on an other interface? -
>> Shouldn't the source address always be translated when an output
>> interface is set (iptables -A POSTROUTING -o eth3 -t nat -j MASQUERADE)?
> The bridging code passes packets through IPv4 netfilter and
> connection tracking, so when they hit your MASQUERADE rule,
> the NAT mappings have already been set up.

Remember my setup veth0 and eth1 bridged together to br0, eth3 is the
outgoing interface.

Cases:

1) The ip address set on the bridge and no ip address on veth1 works
   fine regardless whether bridge-nf-call-iptables is set or unset.

2) The ip set on veth1 and no ip on the bridge the
   MASQUERADE rule is only hit when bridge-nf-call-iptables is unset.

If I understood you correctly then the netfilters (nat/postrouting)
would only be applied once in the latter case when
bridge-nf-call-iptables is enabled.

But if veth should behave like a "regular" interface shouldn't the
netfilter rules be applied twice? - First when the packets enter the
bridge on eth0 and leave it on veth0, and secondly when they enter veth1
and and leave it at the final outgoing interface.

Any hint would be appreciated,
best regards,
Bernhard

Re: Veth problems with bridge

[Patrick McHardy]

Bernhard Miklautz wrote:
> Hi Patrick,
> 
> Patrick McHardy wrote:
>>>>> I also tried the whole setup without using veth; the IP directly bound
>>>>> to br0, as well as without the bridge at all. No problems with that.
>>>>> So there might be some problems with veth?
>>>> Does "echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables" fix it?
>>> On my hardware machine this seems to fix the problem :). But why does
>>> bridge-nf-call-iptables influent source nat on an other interface? -
>>> Shouldn't the source address always be translated when an output
>>> interface is set (iptables -A POSTROUTING -o eth3 -t nat -j MASQUERADE)?
>> The bridging code passes packets through IPv4 netfilter and
>> connection tracking, so when they hit your MASQUERADE rule,
>> the NAT mappings have already been set up.
> 
> Remember my setup veth0 and eth1 bridged together to br0, eth3 is the
> outgoing interface.
> 
> Cases:
> 
> 1) The ip address set on the bridge and no ip address on veth1 works
>    fine regardless whether bridge-nf-call-iptables is set or unset.
> 
> 2) The ip set on veth1 and no ip on the bridge the
>    MASQUERADE rule is only hit when bridge-nf-call-iptables is unset.
> 
> If I understood you correctly then the netfilters (nat/postrouting)
> would only be applied once in the latter case when
> bridge-nf-call-iptables is enabled.

No, they will be applied twice, but NAT mappings are only set up
on the first packet, so when the eth3 rule is hit, its too late.

> But if veth should behave like a "regular" interface shouldn't the
> netfilter rules be applied twice? - First when the packets enter the
> bridge on eth0 and leave it on veth0, and secondly when they enter veth1
> and and leave it at the final outgoing interface.

They are (see above). But NAT is a special case and would need
namespace-aware connection tracking and both veths living in
different namespaces for the scenario you describe (or disabled
IPv4 netfilter for bridging).