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]
Message-ID: <48469ADC.5070800@inqnet.at>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ