[neutron] default(ish) firewall rules

Slawek Kaplonski skaplons at redhat.com
Thu Dec 3 13:10:29 UTC 2020


On Thu, Dec 03, 2020 at 03:47:48PM +0300, Vladimir Prokofev wrote:
> Hello.
> I'm running Queens private cloud with few separate projects inside. Guests
> in those projects have 2 networks - public, which is a provider
> network with public IP addresses, and private which is a VXLAN overlay
> network specific to the project.
> That's the setup, now here's the issue.
> They're mostly Windows guests there, and they tend to have browser service
> enabled on both public and private networks. This leads to situations where
> guests from one project can see guests in other projects over a public
> network via NetBIOS/SMB protocols, which is undesirable.
> I have two partial solutions in mind.
> Create some default firewall rule, similar to that exists by default for
> DHCP protocol that prohibit guests to act as DHCP server, but for UDP
> 137-139 port range.
> But not only I completely forgot how to do this(I think I saw some
> documentation about it ~2 years ago), but this will also block said
> protocol over private networks too, which is not an ideal solution. I would
> still love it if someone could point me to a proper documentation here.
> Second option is to add similar entries to security group rules. This will
> allow public/private interface differentiation by applying different
> security group to different interfaces, but introduces the possibility for
> cloud operator to delete those entries(either by mistake, or explicitly)
> which will lead to protocol being allowed once again.

If You will add rule to SG as an admin user, then regular users (owners of the
SG) will not be able to remove it.
But they will still be able to stop using this SG completly.

> Anyone has any idea of a better solution here?

What if You would plug those VMs only to the private networks and use Floating
IPs to have public connectivity? Would that work for You?

Slawek Kaplonski
Principal Software Engineer
Red Hat

More information about the openstack-discuss mailing list