Hi, When there is 0.0.0.0/0 for dest cidr, while adding iptables do not include ' -m set --match-set destCidrIpset-4 dst’ . For 0.0.0.0/0 no need to add this in ipset.
This should be fixed in VR code. Thanks, Jayapal > On Nov 21, 2017, at 5:22 PM, Rohit Yadav <rohit.ya...@shapeblue.com> wrote: > > Jayapal - I tried that, that leaves the ipset empty and egress traffic does > not work for guest VMs. > > > This is seen in iptables (filter): > > [..snipped..] > -A FW_EGRESS_RULES -m set --match-set destCidrIpset-4 dst -j ACCEPT > -A FW_EGRESS_RULES -j DROP > [..snipped..] > > > And no members are seen: > > > root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4 > Name: destCidrIpset-4 > Type: hash:net > Revision: 6 > Header: family inet hashsize 1024 maxelem 65536 > Size in memory: 352 > References: 1 > Members: > > At this point from a guest VM, egress traffic won't be allowed. > > > However, with the workaround I mentioned (see the bugzilla discussion for > reference) egress works: > > > root@r-4-VM:/var/cache/cloud/processed# ipset list destCidrIpset-4 > Name: destCidrIpset-4 > Type: hash:net > Revision: 6 > Header: family inet hashsize 1024 maxelem 65536 > Size in memory: 480 > References: 1 > Members: > 0.0.0.0/1 > 128.0.0.0/1 > > > - Rohit > > ________________________________ > From: Jayapal Uradi <jayapal.ur...@accelerite.com> > Sent: Tuesday, November 21, 2017 5:15:57 PM > To: dev@cloudstack.apache.org > Subject: Re: egress fw problems in 4.10? > > When there is 0.0.0.0/0 for dest cidr do not add/skip the ipset match option > in iptables. This will fix the issue. > > -Jayapal > > > > rohit.ya...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > On Nov 21, 2017, at 5:07 PM, Rohit Yadav > <rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> wrote: > > Hi Lucian, > > > It looks like a legit bug: https://bugzilla.redhat.com/show_bug.cgi?id=1297092 > > > When you add 0.0.0.0/0 as destination cidr, this execute on VR and fails: > > # ipset add destCidrIpset-4 1.0.0.0/0 > ipset v6.30: The value of the CIDR parameter of the IP address is invalid > > > The workaround are to use these destination cidrs, split in two egress > traffic rules: > > 0.0.0.0/1 and 128.0.0.0/1. > > > Regards. > > ________________________________ > From: Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>> > Sent: Tuesday, November 21, 2017 3:16:00 PM > To: dev > Subject: Re: egress fw problems in 4.10? > > Rohit, > > I see it accepts 0.0.0.0/0 on the source CIDR, but then transforms that into > 10.1.1.0/24 (or whatever), I'd imagine it could do the same with the > destination CIDR and just "rename" 0.0.0.0/0 into 0.0.0.0/1. > However this is not a Cloudstack problem as I see it, it's an ipset > bug/feature, so we should just "deal with it", perhaps update the > documentation at least. > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro<http://www.nux.ro> > > > rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com> > www.shapeblue.com<http://www.shapeblue.com/> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > ----- Original Message ----- > From: "Rohit Yadav" > <rohit.ya...@shapeblue.com<mailto:rohit.ya...@shapeblue.com>> > To: "dev" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> > Sent: Tuesday, 21 November, 2017 09:23:00 > Subject: Re: egress fw problems in 4.10? > > I hit the same issue with the debian9-systemvmtemplate PR. Earlier, the egress > traffic option used to accept 0.0.0.0/0. > > > - Rohit > > ________________________________ > From: Nux! <n...@li.nux.ro<mailto:n...@li.nux.ro>> > Sent: Friday, November 17, 2017 11:09:26 PM > To: dev > Subject: Re: egress fw problems in 4.10? > > Thanks Jayapal, > > Indeed, I checked and 0.0.0.0/0 is not there. When I tried to add it manually > I > got an error: > ipset v6.12.1: The value of the CIDR parameter of the IP address is invalid > > > Hash:net types will not accept 0 prefix, it's happy to accept 0.0.0.0/1 > though, > however I still can't do any egress except for ICMP ping for some reason. > > If I omit specifying a a dest CIDR, then I get trully unrestricted egress. > > I need to investigate some more when I get time, something's fishy. > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro<http://www.nux.ro> > > > rohit.ya...@shapeblue.com > www.shapeblue.com<http://www.shapeblue.com/><http://www.shapeblue.com<http://www.shapeblue.com/>> > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > ----- Original Message ----- > From: "Jayapal Uradi" <jayapal.ur...@accelerite.com> > To: "dev" <dev@cloudstack.apache.org> > Sent: Friday, 17 November, 2017 04:02:13 > Subject: Re: egress fw problems in 4.10? > > Hi Nux, > > I think the the ipset for destination cidr is not configured with 0.0.0.0/0 > due > this you might see this issue. > Please check the ipset and iptables rules once. > > iptables -L -nv > ipset -L > > Thanks, > Jayapal > > > On Nov 17, 2017, a t 6:55 AM, Nux! <n...@li.nux.ro> wrote: > > Hi, > > Just installed 4.10 today for a demo, but seems there are some problems with > the > egress rules in isolated networks. > Is there anything wrong with this rule? ACS allows me to add it, but no > outbound > traffic is allowed at all. > > 10.1.1.0/24 0.0.0.0/0 All All All > > http://img.nux.ro/gL3-Selection_002.png > > If I replace 0.0.0.0/0 with a certain IP/32, then traffic works. > > > Also, if I don't mention a destination cidr at all, outbound traffic also > works, > but the docs state 0.0.0.0/0 should be honoured as valid destination cidr. > > Any ideas? I know there was recent work done on egress recently, maybe related > to that? > > Lucian > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the > property of Accelerite, a Persistent Systems business. It is intended only for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient, you are not authorized to read, retain, copy, print, > distribute or use this message. If you have received this communication in > error, please notify the sender and delete all copies of this message. > Accelerite, a Persistent Systems business does not accept any liability for > virus infected mails. > > DISCLAIMER > ========== > This e-mail may contain privileged and confidential information which is the > property of Accelerite, a Persistent Systems business. It is intended only > for the use of the individual or entity to which it is addressed. If you are > not the intended recipient, you are not authorized to read, retain, copy, > print, distribute or use this message. If you have received this > communication in error, please notify the sender and delete all copies of > this message. Accelerite, a Persistent Systems business does not accept any > liability for virus infected mails.
