> this create a new chain PVEFW-Accept
You use this chain unconditionally, so we slow down things when the IPS is not
active.
(because of an additional jump to PVEFW-Accept).
Besides, I cannot see that this patch replaces all ACCEPT actions, for example:
---
sub ruleset_generate_vm
> It might be worth trying to make a feature request to the qemu-img team
to add this option?
I'll pursue getting this feature added to qemu-img.
> Your patch still needs to handle the case where a VM has been converted
> to a template since image handling after conversion complains of an
> unkno
On Mon, 17 Mar 2014 04:49:53 +
Dietmar Maurer wrote:
>
> Yes (if zfs allocates images initialized with zero).
>
>
I want to test this. How can I assure that adding zfs to this that it
does not fail to properly restore and image?
--
Hilsen/Regards
Michael Rasmussen
Get my public GnuPG ke
On Mon, 17 Mar 2014 11:08:41 -0700
Chris Allen wrote:
>
> Connecting to the target with a host group defined fails unless the
> initiator has been added to the host group, as it should be by design. If
> I manually add the initiator name ("iqn.2008-11.org.linux-kvm:")
> to the host group on the
Michael,
Thanks for testing these. If I supply you with future patches I'll try to
be a little bit more rigorous with testing before I send them in.
Connecting to the target with a host group defined fails unless the
initiator has been added to the host group, as it should be by design. If
I m
Signed-off-by: Alexandre Derumier
This add ips (like suricata) support through nfqueues.
this create a new chain PVEFW-Accept
-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j PVEFW-Accept
-A PVEFW-Accept -m physdev --physdev-out tapxxx --physdev-is-bridged -j NFQUEUE
--queue-num
changelog : use -j PVEFW-Accept everywhere.
Don't have seen any regression
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> >>We can? Or we 'have to' replace that in order to make ips work?
>
> Currently, it's working, when connection is already established.
>
> Only the first ACCEPT is not yet managed.
Ah, OK.
> >>I would like to have a complete patch before I commit this.
>
> Sure ! I'll improve the patch this
>>We can? Or we 'have to' replace that in order to make ips work?
Currently, it's working, when connection is already established.
Only the first ACCEPT is not yet managed.
>>I would like to have a complete patch before I commit this.
Sure ! I'll improve the patch this afternoon.
(I need also
> >>We use '-j ACCEPT' at many places. Each of those calls will bypass the ips?
> >>So shouldn't we replace all occurrences of '-J ACCEPT'?
>
> I only replace when connection is established for now, but I think we can
> replace the -J ACCEPT in tap-in chains without problem.
We can? Or we 'have t
>>We use '-j ACCEPT' at many places. Each of those calls will bypass the ips?
>>So shouldn't we replace all occurrences of '-J ACCEPT'?
I only replace when connection is established for now,
but I think we can replace the -J ACCEPT in tap-in chains without problem.
and in vmbrX-FW chain too.
We use '-j ACCEPT' at many places. Each of those calls will bypass the ips?
So shouldn't we replace all occurrences of '-J ACCEPT'?
> This add ips (like suricata) support through nfqueues.
>
> this create a new chain PVEFW-Accept
>
> -A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j
Please ignore me - I need some more time to review the patch.
> -Original Message-
> From: pve-devel [mailto:pve-devel-boun...@pve.proxmox.com] On Behalf
> Of Dietmar Maurer
> Sent: Montag, 17. März 2014 12:48
> To: Alexandre Derumier; pve-devel@pve.proxmox.com
> Subject: Re: [pve-devel] [
> # fixme: this is an optimization? if so, we should also drop INVALID
> packages?
> -ruleset_insertrule($ruleset, "PVEFW-FORWARD", "-m conntrack --ctstate
> RELATED,ESTABLISHED -j ACCEPT");
> -
> +ruleset_insertrule($ruleset, "PVEFW-FORWARD", "-m conntrack
> + --ctstate RELATED,ESTABL
Signed-off-by: Alexandre Derumier
This add ips (like suricata) support through nfqueues.
this create a new chain PVEFW-Accept
-A PVEFW-FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j PVEFW-Accept
-A PVEFW-Accept -m physdev --physdev-out tapxxx --physdev-is-bridged -j NFQUEUE
--queue-num
see commit.
(I don't have tested with openvz vnet0)
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> -Original Message-
> From: Alexandre DERUMIER [mailto:aderum...@odiso.com]
> Sent: Montag, 17. März 2014 08:14
> To: Dietmar Maurer
> Cc: pve-devel@pve.proxmox.com
> Subject: Re: [pve-devel] [PATCH] add ips feature
>
> Well, we jump to NFQUEUE in tap chains.
>
> If we ACCEPT at begin
Well, we jump to NFQUEUE in tap chains.
If we ACCEPT at begin of forward, we bypass ip.
and we jump to NFQUEUE at begin of forward, we are going to ips for all vms (I
want to enable it by vm)
I just notice a bug, if sourcevm out (ips:0) -> sourcevm in (ips:1)
it'll do an accept in tap-out, and
18 matches
Mail list logo
