Re: Change default egresss rule
I am using Advanced Networking mode. I want to block some destination CIDRs (Egress) for some VM instances. I have currently one shared guest network with default egress allowed. I want to create another shared network with default egress denied so I can explicitly allow all outbound traffic except those CIDRs. When you create a new Network Offering, UI does not have any option to choose default Egress rule for and it is dictated by zone settings. On Tue, Nov 5, 2019 at 1:15 AM Riepl, Gregor (SWISS TXT) < gregor.ri...@swisstxt.ch> wrote: > Hi Fariborz, > > Sorry, I don't quite understand what you're referring to. > > For Advanced Networking with a virtual router, you have to create egress > rules yourself, using > https://cloudstack.apache.org/api/apidocs-4.11/apis/createEgressFirewallRule.html > or the UI. The same applies to VPCs. > > On Basic Networks, you should be able to use SecurityGroups: > > http://docs.cloudstack.apache.org/en/latest/adminguide/networking/security_groups.html > > The Security Group APIs are separate from the Instance APIs, so you can > create your SG, apply egress rules, then apply the SG to the instance via > the deployVirtualMachine securitygroupnames parameter. > > Which kind of network are you using? > > Regards, > Gregor > > From: Fariborz Navidan > Sent: 04 November 2019 18:38 > To: users@cloudstack.apache.org > Subject: Change default egresss rule > > Hello, > > When create a new network, there is no option to choose default egress > rule. How can we change it before creating VM on that network? >
Re: Change default egresss rule
Hi Fariborz, Sorry, I don't quite understand what you're referring to. For Advanced Networking with a virtual router, you have to create egress rules yourself, using https://cloudstack.apache.org/api/apidocs-4.11/apis/createEgressFirewallRule.html or the UI. The same applies to VPCs. On Basic Networks, you should be able to use SecurityGroups: http://docs.cloudstack.apache.org/en/latest/adminguide/networking/security_groups.html The Security Group APIs are separate from the Instance APIs, so you can create your SG, apply egress rules, then apply the SG to the instance via the deployVirtualMachine securitygroupnames parameter. Which kind of network are you using? Regards, Gregor From: Fariborz Navidan Sent: 04 November 2019 18:38 To: users@cloudstack.apache.org Subject: Change default egresss rule Hello, When create a new network, there is no option to choose default egress rule. How can we change it before creating VM on that network?
Re: Security Groups default behavior
Hi Paul, Thanks for your quick answer ! Florent - Mail original - > De: "Paul Angus" > À: "users" > Envoyé: Lundi 4 Novembre 2019 18:20:11 > Objet: RE: Security Groups default behavior > Hi Florent, > > No, two VMs in the same security group will have the same rules applied to > them. > So if they both allow outbound port 22, they won't be able to talk over SSH, > as neither allows inbound SSH. > > If your network was created with a default allow, then they will be able to > communicate over all ports until you start applying rules to them. > > Paul. > > paul.an...@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > > > > -Original Message- > From: Florent Paillot > Sent: 04 November 2019 16:01 > To: cs users > Subject: Security Groups default behavior > > Hello, > I'm looking for the default behavior for Security Groups when using a shared > network with SG support. Can't find it in the docs. > Are two VM in the same SG implicitly allowed to communicate with each other ? > > Maybe i'm wrong but it's seemed to be the case with 4.9.3 (KVM) but not > anymore > with 4.11.3 (KVM). > > Thanks
Change default egresss rule
Hello, When create a new network, there is no option to choose default egress rule. How can we change it before creating VM on that network?
RE: Security Groups default behavior
Hi Florent, No, two VMs in the same security group will have the same rules applied to them. So if they both allow outbound port 22, they won't be able to talk over SSH, as neither allows inbound SSH. If your network was created with a default allow, then they will be able to communicate over all ports until you start applying rules to them. Paul. paul.an...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue -Original Message- From: Florent Paillot Sent: 04 November 2019 16:01 To: cs users Subject: Security Groups default behavior Hello, I'm looking for the default behavior for Security Groups when using a shared network with SG support. Can't find it in the docs. Are two VM in the same SG implicitly allowed to communicate with each other ? Maybe i'm wrong but it's seemed to be the case with 4.9.3 (KVM) but not anymore with 4.11.3 (KVM). Thanks
Security Groups default behavior
Hello, I'm looking for the default behavior for Security Groups when using a shared network with SG support. Can't find it in the docs. Are two VM in the same SG implicitly allowed to communicate with each other ? Maybe i'm wrong but it's seemed to be the case with 4.9.3 (KVM) but not anymore with 4.11.3 (KVM). Thanks
Re: SystemVM Storage Tags not taken into account?
There's nothing in the API or the UI. We just change it in the DB. On Mon, 4 Nov 2019 at 13:48, Melanie Desaive wrote: > > Hi Richard, > > thank you for this hint. > > I had a look in the database, and yes, all Network Offeringns in the > table network_offerings still reference the old System/Disk offering > IDs from disk_offering/system_offering. > > Is there an intended way to change > "network_offerings.service_offering_id" for an existing network > offering? Would it be ok to update the database? Is there an API call? > I did not find anything in the documentation. > > Kind regards, > > Melanie > > > > Am Freitag, den 01.11.2019, 09:25 + schrieb Richard Lawley: > > Melanie, > > > > > Maybe the procedure for resetting the System Offering for Virtual > > > Routers differs from that for SSVM and CP and I missed some point? > > > > The System Offering for Virtual Routers is not taken from the same > > place as SSVM/CP - it's set on the Network Offering instead, so you > > can have different network offerings with different system offerings. > > > > Regards, > > > > Richard > > > > On Fri, 1 Nov 2019 at 08:33, Melanie Desaive > > wrote: > > > Good morning Andrija, > > > > > > yes, I did restart mgmt. Documentation states that. > > > > > > Interestingly the documentation in > > > http://docs.cloudstack.apache.org/en/4.11.1.0/adminguide/service_offerings.html#changing-the-default-system-offering-for-system-vms > > > only mentions only resetting the unique_names for Secondary Storage > > > VM > > > and Console Proxy VM not for the Virtual Routers in the database. > > > > > > Maybe the procedure for resetting the System Offering for Virtual > > > Routers differs from that for SSVM and CP and I missed some point? > > > > > > Greetings, > > > > > > Melanie > > > > > > Am Donnerstag, den 31.10.2019, 17:19 +0100 schrieb Andrija Panic: > > > > tried restarting mgmt after tag change? Usually not required but > > > > might be > > > > for systemVMs. > > > > > > > > On Thu, 31 Oct 2019, 15:21 Melanie Desaive, < > > > > m.desa...@mailbox.org> > > > > wrote: > > > > > > > > > Hi all, > > > > > > > > > > I just tried to set up storage tags for System VMs, but the > > > > > behaviour > > > > > is not as expected. The deployment planner does not seem to > > > > > take > > > > > the > > > > > storage tag into account when deciding over the storage. > > > > > > > > > > -- > > > > > > > > > > The only storage with the tag "SYSTEMV" ist "ACS-LUN-SAS-01' > > > > > with > > > > > id=10 > > > > > > > > > > mysql> select id,name,tag from storage_pool_view where > > > > > cluster_name > > > > > = > > > > > 'cluster2' and status = 'Up' and tag = 'SYSTEMVM' order by > > > > > name,tag; > > > > > +++--+ > > > > > > id | name | tag | > > > > > +++--+ > > > > > > 10 | ACS-LUN-SAS-01 | SYSTEMVM | > > > > > +++--+ > > > > > 1 row in set (0,00 sec) > > > > > > > > > > -- > > > > > > > > > > I definied the tag "SYSTEVM" for the System Offering for the > > > > > Virtual > > > > > Routers: > > > > > > > > > > mysql> select id,name,unique_name,type,state,tags from > > > > > disk_offering > > > > > where type='Service' and state='Active' and unique_name like > > > > > 'Cloud.Com-SoftwareRouter' order by unique_name \G > > > > > *** 1. row *** > > > > > id: 281 > > > > >name: System Offering For Software Router - With Tags > > > > > unique_name: Cloud.Com-SoftwareRouter > > > > >type: Service > > > > > state: Active > > > > >tags: SYSTEMVM > > > > > 1 row in set (0,00 sec) > > > > > > > > > > -- > > > > > > > > > > But when I redeploy a virtual Router the deployment planner > > > > > takes > > > > > all > > > > > storages into account. :( > > > > > > > > > > The log saies explicitely "Pools matching tags..." and lists > > > > > several > > > > > other pools. > > > > > What do I miss? > > > > > > > > > > -- > > > > > ClusterScopeStoragePoolAllocator looking for storage pool > > > > > Looking for pools in dc: 1 pod:1 cluster:3. Disabled pools > > > > > will > > > > > be > > > > > ignored. > > > > > Found pools matching tags: [Pool[7|PreSetup], Pool[9|PreSetup], > > > > > Pool[10|PreSetup], Pool[18|PreSetup]] > > > > > ClusterScopeStoragePoolAllocator returning 3 suitable storage > > > > > pools > > > > > ClusterScopeStoragePoolAllocator looking for storage pool > > > > > Looking for pools in dc: 1 pod:1 cluster:3. Disabled pools > > > > > will > > > > > be > > > > > ignored. > > > > > Found pools matching tags: [Pool[7|PreSetup], Pool[9|PreSetup], > > > > > Pool[10|PreSetup], Pool[18|PreSetup]] > > > > > ClusterScopeStoragePoolAllocator returning 3 suitable storage > > > > > pools > > > > > -- > > > > > > > > > > Kind regards, > > > > > > > > > > Melanie > > > > > >
Re: Does traffic touches VR when gateway is is not on the cloud network?
Any idea? On Sat, Nov 2, 2019 at 5:22 PM Fariborz Navidan wrote: > Thanks for reply. How should we block a egress CIDR from specific source > CIDR when default egress policy of the network offering is "Allow"? What > will be behavior of Egress rules in a SG on the network? > > On Sat, Nov 2, 2019 at 12:09 AM Andrija Panic > wrote: > >> By the definition, with Shared Networks, VR is providing **ONLY** >> DNS/DHCP/USER-DATA services to VMs in the shared network - i.e. traffic >> NEVER passes through the VR (your VR and all your user VMs have an IP on >> that shared network - they are just "peers" so to speak, VR is not a >> router, it's just a dhcp/dns server). >> >> If you are using Security Groups on that shared network, then you can >> achieve what you want via SG, otherwise, your VMs are using (as you >> stated) >> external gateway, which you don't control. >> >> If you are NOT using SG, but are brave enough and have awesome automation >> skills - you can try to do traffic limiting on the hypervisor hosts (which >> is exactly what SG do - SG is just a collection of iptables/ebtables rules >> on hypervisors) >> Though I would not advise doing so...^^^ >> >> Best, >> Andrija >> >> On Fri, 1 Nov 2019 at 21:21, Fariborz Navidan >> wrote: >> >> > Yes, it is a shared network with external gateway. Indeed hosts are >> > connected to a vRack on OVH network. Gateway address is externally >> > addressed as last usable IP of the IP block. On CloudStack side, we >> have I >> > have configured several IP address ranges on the same shared guest >> network >> > in an advanced zone. >> > >> > What I want to do is, to block some outgoing traffic from specific >> source >> > IPs rto specific destination IP ranges. I want to know that I should >> place >> > firewall rule on theVR or on the host itself. The cloud is currently >> > running with one host but I should be able to generalize this rules for >> > further scaling when more hosts are added in future. >> > >> > Thanks >> > >> > On Fri, Nov 1, 2019 at 10:30 PM Andrija Panic >> > wrote: >> > >> > > Can you explain your setup a bit more - I'm not clear with "gateway >> > address >> > > of my guest network is not inside the cloud and it is >> > > not under my management" - is this a shared network, using some >> external >> > > gateway (which is a normal setup for Shared network)? >> > > >> > > On Fri, 1 Nov 2019 at 16:21, Fariborz Navidan >> > > wrote: >> > > >> > > > Hello, >> > > > >> > > > The gateway address of my guest network is not inside the cloud and >> it >> > is >> > > > not under my management. My question is that does guest traffic >> still >> > > touch >> > > > the virtual router and can I place custom firewall rules between >> guests >> > > and >> > > > outside network on VR? >> > > > >> > > >> > > >> > > -- >> > > >> > > Andrija Panić >> > > >> > >> >> >> -- >> >> Andrija Panić >> >
Re: SystemVM Storage Tags not taken into account?
Hi Richard, thank you for this hint. I had a look in the database, and yes, all Network Offeringns in the table network_offerings still reference the old System/Disk offering IDs from disk_offering/system_offering. Is there an intended way to change "network_offerings.service_offering_id" for an existing network offering? Would it be ok to update the database? Is there an API call? I did not find anything in the documentation. Kind regards, Melanie Am Freitag, den 01.11.2019, 09:25 + schrieb Richard Lawley: > Melanie, > > > Maybe the procedure for resetting the System Offering for Virtual > > Routers differs from that for SSVM and CP and I missed some point? > > The System Offering for Virtual Routers is not taken from the same > place as SSVM/CP - it's set on the Network Offering instead, so you > can have different network offerings with different system offerings. > > Regards, > > Richard > > On Fri, 1 Nov 2019 at 08:33, Melanie Desaive > wrote: > > Good morning Andrija, > > > > yes, I did restart mgmt. Documentation states that. > > > > Interestingly the documentation in > > http://docs.cloudstack.apache.org/en/4.11.1.0/adminguide/service_offerings.html#changing-the-default-system-offering-for-system-vms > > only mentions only resetting the unique_names for Secondary Storage > > VM > > and Console Proxy VM not for the Virtual Routers in the database. > > > > Maybe the procedure for resetting the System Offering for Virtual > > Routers differs from that for SSVM and CP and I missed some point? > > > > Greetings, > > > > Melanie > > > > Am Donnerstag, den 31.10.2019, 17:19 +0100 schrieb Andrija Panic: > > > tried restarting mgmt after tag change? Usually not required but > > > might be > > > for systemVMs. > > > > > > On Thu, 31 Oct 2019, 15:21 Melanie Desaive, < > > > m.desa...@mailbox.org> > > > wrote: > > > > > > > Hi all, > > > > > > > > I just tried to set up storage tags for System VMs, but the > > > > behaviour > > > > is not as expected. The deployment planner does not seem to > > > > take > > > > the > > > > storage tag into account when deciding over the storage. > > > > > > > > -- > > > > > > > > The only storage with the tag "SYSTEMV" ist "ACS-LUN-SAS-01' > > > > with > > > > id=10 > > > > > > > > mysql> select id,name,tag from storage_pool_view where > > > > cluster_name > > > > = > > > > 'cluster2' and status = 'Up' and tag = 'SYSTEMVM' order by > > > > name,tag; > > > > +++--+ > > > > > id | name | tag | > > > > +++--+ > > > > > 10 | ACS-LUN-SAS-01 | SYSTEMVM | > > > > +++--+ > > > > 1 row in set (0,00 sec) > > > > > > > > -- > > > > > > > > I definied the tag "SYSTEVM" for the System Offering for the > > > > Virtual > > > > Routers: > > > > > > > > mysql> select id,name,unique_name,type,state,tags from > > > > disk_offering > > > > where type='Service' and state='Active' and unique_name like > > > > 'Cloud.Com-SoftwareRouter' order by unique_name \G > > > > *** 1. row *** > > > > id: 281 > > > >name: System Offering For Software Router - With Tags > > > > unique_name: Cloud.Com-SoftwareRouter > > > >type: Service > > > > state: Active > > > >tags: SYSTEMVM > > > > 1 row in set (0,00 sec) > > > > > > > > -- > > > > > > > > But when I redeploy a virtual Router the deployment planner > > > > takes > > > > all > > > > storages into account. :( > > > > > > > > The log saies explicitely "Pools matching tags..." and lists > > > > several > > > > other pools. > > > > What do I miss? > > > > > > > > -- > > > > ClusterScopeStoragePoolAllocator looking for storage pool > > > > Looking for pools in dc: 1 pod:1 cluster:3. Disabled pools > > > > will > > > > be > > > > ignored. > > > > Found pools matching tags: [Pool[7|PreSetup], Pool[9|PreSetup], > > > > Pool[10|PreSetup], Pool[18|PreSetup]] > > > > ClusterScopeStoragePoolAllocator returning 3 suitable storage > > > > pools > > > > ClusterScopeStoragePoolAllocator looking for storage pool > > > > Looking for pools in dc: 1 pod:1 cluster:3. Disabled pools > > > > will > > > > be > > > > ignored. > > > > Found pools matching tags: [Pool[7|PreSetup], Pool[9|PreSetup], > > > > Pool[10|PreSetup], Pool[18|PreSetup]] > > > > ClusterScopeStoragePoolAllocator returning 3 suitable storage > > > > pools > > > > -- > > > > > > > > Kind regards, > > > > > > > > Melanie > > > >
