netdev - Re: Veth problems with bridge

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Jun 2008 15:38:36 +0200
From:	Bernhard Miklautz <miklautz@...net.at>
To:	Patrick McHardy <kaber@...sh.net>
CC:	linux-net@...r.kernel.org,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: Veth problems with bridge

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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html