Hi Eric Lee, Thanks for detail explanation. You shed some light to my doubts.
Regards, Netlynker On Thu, 27 Sep 2018 at 9:37 AM, Eric Lee Green <eric.lee.gr...@gmail.com> wrote: > On 9/26/18 6:21 PM, Netlynker wrote: > > Hi Eric, > > > > Usual setup for my other infra service is that we use external firewall > > doing NAT and protecting the resource behind. The public IP will stay on > > that firewall and it is NATed to private IP of the service internal. > > > > What CS document imply is to put “real” public IP address on System VMs > and > > VR which will leave those systems exposed directly to outside world. > > That is the configuration for a public Cloudstack service. If you are a > corporation setting up a private cloud within a corporation, the "public > address" should be routed to your corporate network. For example, my > corporate "floor" network that goes to the desktops on people's desks is > 10.100.0.0/16 while my corporate "wifi" is 10.101.0.0/16. I gave my > Cloudstack cluster the public address of 10.102.0.0/16 which is routed > to my external firewall router via a VLAN-enabled Cisco Layer 3 switch > to the actual firewall on the external DMZ VLAN 10.2.0.0/24. (Other > private networks such as the pool for VPC creation use additional 10.x > subnets). The 10.102.x.y addresses are "internet" addresses as far as > Cloudstack is concerned -- they can access the Internet. The fact that > they're accessing it via my corporate network rather than being directly > connected to the Internet is irrelevant. > > As far as the safety of the router virtual machines, they are a small > Linux distribution just like the one in your external firewall, that, > like the one in your external firewall, is configured with routes and > firewall rules to be secure. If you were doing a public-facing Internet > service there would be no problem putting them directly on the public > Internet. From a design perspective they're no more or less secure than > your current NAT firewall, which is also a small Linux distribution > unless it's a Cisco. Whether you want to put them directly onto the > Internet or not depends on your design goals, not safety. If you want to > be able to access your virtual machines from the public Internet without > logging in via a VPN, such as publicly available services, then a NAT > firewall between your Cloudstack service and your virtual machines will > not allow for that. If you are satisfied with having your virtual > machines only be reachable from your corporate network and comfortable > with VPN access for those times you need to access them remotely, then > sure, put them on your corporate network behind the NAT firewall. That's > what I do, because my production virtual machines providing service to > the general public are running on the Amazon cloud, my Cloudstack > installation is for corporate-private R&D and support instances that the > general public isn't supposed to access. > > > My question is if that architecture is recommeneded and how safe it is to > > put “real” public IP on System VMs and VRs directly. > > > > Thanks in advance, > > Netlynker > > > > On Thu, 27 Sep 2018 at 8:58 AM, Eric Lee Green <eric.lee.gr...@gmail.com > > > > wrote: > > > >> On 9/25/18 6:29 PM, Netlynker wrote: > >>> Hi, > >>> > >>> I looked at the deployment architecture from document and it said to > have > >>> public IP addresses on Virtaul Router/System VMs. > >>> > >>> Is that recommended setup? > >>> > >>> How safe will it be to expose Virtaul Router/ System VMs directly to > >>> internet? > >> > >> If a virtual router is not connected to the Internet, how will it route > >> traffic from your internal VM's in their virtual private networks to the > >> Internet? Magic? (This presuming you have an Internet-facing service, > >> but even if it's internal to your company, the virtual router is going > >> to need to be able to talk to the Internet via your company's "internal" > >> Internet network if your internal VM's on their own internal private > >> networks are going to get to the Internet or other corporate resources). > >> > >> > >> > >> > >
