> I'm a bit lost for now, I'll try to create a testlab tomorrow to see how
> things
> works.
I currently use the following configuration for testing:
---
auto vmbr0
iface vmbr0 inet manual
bridge_ports eth0
bridge_stp off
bridge_fd 0
auto pm0
iface pm
> >>We need physdev match to filter traffic from VMs?
> sorry, I wanted to say, output interface instead phydev
>
> >>iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j
> MASQUERADE
> replace by
>
> iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -j SNAT --to X.X.X.X (ip of
> the bri
Congratulations and much appreciated!
Has been working great for me, good job everyone - thanks.
On 10 March 2014 21:50, Martin Maurer wrote:
> Hi all,
>
> We just released Proxmox VE 3.2, introducing great new features! More SPICE
> with spiceterm, Ceph Server integration, Open vSwitch and mor
>>We need physdev match to filter traffic from VMs?
sorry, I wanted to say, output interface instead phydev
>>iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o vmbr0 -j MASQUERADE
replace by
iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -j SNAT --to X.X.X.X (ip of
the bridge)
how is the
> >>That behaves quite the same.
>
> Maybe, without veth ? (using bridge ip directly?).
> So we don't need to have physdev match.
We need physdev match to filter traffic from VMs?
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.c
>>That behaves quite the same.
Maybe, without veth ? (using bridge ip directly?).
So we don't need to have physdev match.
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: pve-devel@pve.proxmox.com
Envoyé: Lundi 10 Mars 2014 16:07:32
Objet: RE: [pve-devel] pvefw
> also, as MASQUERADE alternative, maybe it could work better with SNAT ?
> (using ip of output device, instead physdev)
>
>
> iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -j SNAT -to-source
> X.X.X.X(replace by ip of the output device)
That behaves quite the same.
__
> just found this, not sure it's related:
>
> http://www.spinics.net/lists/netfilter-devel/msg13554.html
Thanks for that link. But it looks that also use --zone, so this just adds
another level of confusion to me ;-)
___
pve-devel mailing list
pve-deve
> is doing his job, to nat only on pm0
>
>
> now, I don't known for the --zone 1 .
> (So it doesn't work on 2.6.32 without --zone 1 ?)
it does not work with 3..6.32 without --zone 1
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.pr
also, as MASQUERADE alternative, maybe it could work better with SNAT ? (using
ip of output device, instead physdev)
iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -j SNAT -to-source
X.X.X.X(replace by ip of the output device)
- Mail original -
De: "Alexandre DERUMIER"
À: "Diet
just found this, not sure it's related:
http://www.spinics.net/lists/netfilter-devel/msg13554.html
"2.6.34 introduced 'conntrack zones' to deal with cases where packets
from multiple identical networks are handled by conntrack/NAT. Packets
are looped through veth devices, during which
>>Oh, I have a second bridge configured as:
oh,ok.
so, it seem that
>>iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -j LOG --log-prefix
>>"MASQTEST: "
show, that packet with source 10.10.10.0/24 in POSTROUTING, is tested against
each output interface (maybe interfaces with ip adress con
> >>Mar 10 11:25:34 lola kernel: [259254.043987] MASQTEST: IN= OUT=vmbr1
> >>PHYSIN=tap116i0 PHYSOUT=pm1peer SRC=10.10.10.3 DST=8.8.8.8 LEN=84
> >>TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0
> ID=5639
> >>SEQ=1 >>MARK=0x1 Mar 10 11:25:34 lola kernel: [259254.044020]
> >>MASQTEST: IN=
Hi all,
We just released Proxmox VE 3.2, introducing great new features! More SPICE
with spiceterm, Ceph Server integration, Open vSwitch and more!
Together with this release, we started publishing a new series of short video
tutorials, e.g. "What´s new in Proxmox VE 3.2!", see http://youtu.be/U
> >>So it seem that now the POSTROUTING chain gets called twice. The second
> call has the correct output interface.
>
> what is pm0 vs pm1peer ?
Oh, I have a second bridge configured as:
auto vmbr0
iface vmbr0 inet manual
bridge_ports bond0
bridge_stp off
bridge_fd 0
au
>>Mar 10 11:25:34 lola kernel: [259254.043987] MASQTEST: IN= OUT=vmbr1
>>PHYSIN=tap116i0 PHYSOUT=pm1peer SRC=10.10.10.3 DST=8.8.8.8 LEN=84 TOS=0x00
>>PREC=0x00 TTL=64 ID=0 DF PROTO=ICMP TYPE=8 CODE=0 ID=5639 SEQ=1 >>MARK=0x1
>>Mar 10 11:25:34 lola kernel: [259254.044020] MASQTEST: IN= OUT=pm0
>
> > post-up iptables -t raw -A PREROUTING -s '10.10.10.0/24' -i vmbr1 -j
> > CT --zone
> > 1 # why do we need this?
> > post-up iptables -t raw -A PREROUTING -d '10.10.10.0/24' -i vmbr1 -j
> > CT -- zone 1 # why do we need this?
> > post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o pm0 -
> post-up iptables -t raw -A PREROUTING -s '10.10.10.0/24' -i vmbr1 -j CT --zone
> 1 # why do we need this?
> post-up iptables -t raw -A PREROUTING -d '10.10.10.0/24' -i vmbr1 -j CT --
> zone 1 # why do we need this?
> post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24' -o pm0 -j
> MASQUERADE
Hi,
I'm back from holiday !
>>But I do not understand this. Why is that required? Is that the correct way
>>to do it?
I'm not sure, but
post-up iptables -t raw -A PREROUTING -s '10.10.10.0/24' -i vmbr1 -j CT --zone
1 # why do we need this?
post-up iptables -t raw -A PREROUTING -d '10.10.1
The following configuration to MASQUERADE traffic is known to work:
auto vmbr1
iface vmbr1 inet static
address 10.10.10.1
netmask 255.255.255.0
bridge_ports none
bridge_stp off
bridge_fd 0
post-up iptables -t nat -A POSTROUTING -s '10.10.10.0/24'
20 matches
Mail list logo
