On Fri, Apr 13, 2018 at 11:18:07AM +0200, Mark Schouten wrote:
> On Fri, 2018-04-13 at 11:11 +0200, Wolfgang Bumiller wrote:
> > For simple connections this works, but then you also break multicast
> > traffic unless you add all multicast IPs to the ipfilter as well. The
> > real solution would be to move the conntrack rules from PVEFW-FORWARD
> > into tap/veth${vmid}i* to below the ipfilter.
> 
> True. But moving the conntrack rules to every individual chain extends
> the ruleset, a lot. Multicast addresses are pretty much limited to
> two(?) subnets, which could be added to an already existing ipset,
> which the kernel already visits.
> 
> I'm no kernel guru, I have the feeling that increasing the ruleset is
> more resourcehungry.

A bit, sure, but it may not be that bad. According to
itpables-extensions(8) the 'established' state has already seen packets
in both directions, so it may be enough to just move the 'related' rule
into the VM chains. Would have to test UDP (since it's connection-less,
but the wording is pretty clear that packets in both directions must
have already happened at least once). That way fully-established
connections would still take the fast path.

> Either way, it would be great if this would be fixed!

Agreed.

_______________________________________________
pve-user mailing list
pve-user@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user

Reply via email to