> >>If you have several bridges with assigned IPs, traffic can be routed
> >>from one VM to another VM on different bridge. This will bypass all your
> firewall rules!
>
> Can you provide an network schema with guest and bridge ip address for this
> example ?
vmbr0(10.1.0.1/24) => VM1(10.1.0.2)
>>If you have several bridges with assigned IPs, traffic can be routed from one
>>VM to another VM on different bridge. This will bypass all your firewall
>>rules!
Can you provide an network schema with guest and bridge ip address for this
example ?
- Mail original -
De: "Alexand
>>That is the other direction? I talk about OUTPUT from HOST into VM
I wanted to say,that connection can't be established because the return packet
is blocked in input.
But indeed, they are incoming packets from host to tap.
(I have tested with ping and ssh from host to guest , I never get respo
> I want to build some GUI Plugin for Proxmox that will help to limit the OpenVZ
> Containers bandwidth few Options for Implementation:
> 1. Use rrdtool - http://oss.oetiker.ch/rrdtool
rrdtool is just a database
> 2. Use CBQ.init -
> http://sourceforge.net/projects/cbqinit
> 3. Use TC - http://o
> >>The problem is that all routed traffic from HOST to VM is allowed. So
> >>a good test would be trying to block something.
>
> yes, but return packet (tap-->input) is blocked, so you can't established a
> connection
> iptables -A INPUT -m physdev --physdev-in tap115i0 -j DROP
>
> or
>
> ipt
>>The problem is that all routed traffic from HOST to VM is allowed. So a good
>>test
>>would be trying to block something.
yes, but return packet (tap-->input) is blocked, so you can't established a
connection
iptables -A INPUT -m physdev --physdev-in tap115i0 -j DROP
or
iptables -A INPUT
> >>But they test everything twice that way?
>
> Yes, I don't known why.
> maybe they want to be sure that tap to tap filtering is done only on known tap
> interfaces with firewall enable ?
Yes, I think so.
But one could avoid double checks by using '-j cleaup-chain' instead of
using RETURN in
>>But they test everything twice that way?
Yes, I don't known why.
maybe they want to be sure that tap to tap filtering is done only on known tap
interfaces with firewall enable ?
- Mail original -
De: "Dietmar Maurer"
À: "Alexandre DERUMIER"
Cc: "pve-devel"
Envoyé: Jeudi 23 Ja
Hi,
I want to build some GUI Plugin for Proxmox that will help to limit the
OpenVZ Containers bandwidth
few Options for Implementation:
1. Use rrdtool - http://oss.oetiker.ch/rrdtool
2. Use CBQ.init - http://sourceforge.net/projects/cbqinit
3. Use TC - http://openvz.org/Traffic_shap
From the ceph mailing:
we should backport libleveldb1 from jessy to avoid bug
- Mail transféré -
De: "Sylvain Munaut"
À: "Alexandre DERUMIER"
Cc: "Mark Nelson" , ceph-us...@lists.ceph.com
Envoyé: Jeudi 23 Janvier 2014 17:07:20
Objet: Re: [ceph-users] One specific OSD process usi
> By the way, I understand now why they are doing this:
>
> -A proxmoxfw-FORWARD -m physdev --physdev-out tap110i0 --physdev-is-
> bridged -j tapchains
> -A proxmoxfw-FORWARD -m physdev --physdev-in tap110i0 --physdev-is-
> bridged -j tapchains
> -A proxmoxfw-FORWARD -m physdev --physdev-out tap11
> >>Maybe no big problem unless the user assigns IP addresses to multiple
> bridges.
>
> I'll do test today. Because I known openstack can use dhcpd from host
The problem is that all routed traffic from HOST to VM is allowed. So a good
test
would be trying to block something.
__
By the way, I understand now why they are doing this:
-A proxmoxfw-FORWARD -m physdev --physdev-out tap110i0 --physdev-is-bridged -j
tapchains
-A proxmoxfw-FORWARD -m physdev --physdev-in tap110i0 --physdev-is-bridged -j
tapchains
-A proxmoxfw-FORWARD -m physdev --physdev-out tap115i0 --physdev-
13 matches
Mail list logo