Ok. I'll bite. :) Security is like a castle. More walls provide more protection. One outer wall only is something that tends to bite folks because they assume the first wall won't ever be breached.
Nat is one type of wall. Not to be used by itself but provides additional protection. For example, I witnessed an organization recently misconfigure their firewall rules by accedent and all of the private servers were suddenly accessible from the internet. If these same machines were on private nated space, the failure in the firewall wall, would have not immediately exposed all of the private servers to unexpected attack. They would be protected by the fact that the ip's weren't routeable. Nat's just another tool for the toolbox. its not good, or evil. Its useful though, so stop trying to kill it. Thanks, Kevin ________________________________ From: Salvatore Orlando [salv.orla...@gmail.com] Sent: Wednesday, April 06, 2016 1:19 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Floating IPs and Public IPs are not equivalent Hey! This sounds like bike-shedding & yak-shaving... totally my thing! It is true that the Neutron model currently kind of forces a two-level topology, with the external network being a sort of special case. Regardless, this does not mean you cannot assign directly public IPs to your instances - Neutron routers also work without NAT. Shall we start a discussion on the evils of NAT now? To me is one of those things like landline telephones. You don't really need them, you know how to do without them, but for some reason you keep using them and perceiving them as a fundamental service. As for the issue Kevin pointed out, that's a limitation of the current reference implementation that if overcome will probably simplify the Neutron control plane as well. Salvatore On 2 April 2016 at 00:05, Kevin Benton <ke...@benton.pub<mailto:ke...@benton.pub>> wrote: The main barrier to this is that we need to stop using the 'external_network_bridge = br-ex' option for the L3 agent and define a bridge mapping on the L2 agent. Otherwise the external network is treated as a special case and the VMs won't actually be able to get wired into the external network. On Thu, Mar 31, 2016 at 12:58 PM, Sean Dague <s...@dague.net<mailto:s...@dague.net>> wrote: On 03/31/2016 01:23 PM, Monty Taylor wrote: > Just a friendly reminder to everyone - floating IPs are not synonymous > with Public IPs in OpenStack. > > The most common (and growing, thank you to the beta of the new > Dreamcompute cloud) configuration for Public Clouds is directly assign > public IPs to VMs without requiring a user to create a floating IP. > > I have heard that the require-floating-ip model is very common for > private clouds. While I find that even stranger, as the need to run NAT > inside of another NAT is bizarre, it is what it is. > > Both models are common enough that pretty much anything that wants to > consume OpenStack VMs needs to account for both possibilities. > > It would be really great if we could get the default config in devstack > to be to have a shared direct-attached network that can also have a > router attached to it and provider floating ips, since that scenario > actually allows interacting with both models (and is actually the most > common config across the OpenStack public clouds) If someone has the the pattern for what that config looks like, especially if it could work on single interface machines, that would be great. The current defaults in devstack are mostly there for legacy reasons (and because they work everywhere), and for activation energy to getting a new robust work everywhere setup. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
