cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus <shadow...@gmail.com>
Subject Re: VPC Firewall Rule Limitations
Date Fri, 15 May 2015 07:16:48 GMT
It's possible to do, but there's some work involved. We'd have to modify
the table that stores the rules, then pass that in the ACL commands that
change the iptables rules.

It goes against the idea of tiers, though. A tier is supposed to represent
a given function, your mail server and web server should probably be in
separate tiers, or your mail sever should also be a web server, and your
web server also a mail server, if they are to be in the same tier.

On Wed, May 13, 2015 at 10:47 AM, Christopher Falk <
christopher.falk@reliablenetworks.com> wrote:

> Hi all,
>
> I've run into some limitations in the firewall rule capabilities in the
> VPC side that I'm hoping could be addressed in a future release. For VPC
> networks, when configuring ACL for tiers you can only manage tier-wide
> destinations for inbound or sources for outbound.
>
> What would it take to build in more granularity to these options?
>
> For example, in a tier with one web server and one mail server, I have to
> allow Inbound, from 0.0.0.0/0, on TCP 25, 80, 443 etc. This opens these
> ports to *all* instances in the tier, assuming they don't have their own
> OS-level firewalls running. Now of course only instances with Static NAT
> configured will pass traffic but that still permits port 25 to the web
> server and 80/443 to the FTP even if I don't want that.
>
> Typical firewall rule sets allow source/destination to be specified, so
> that we could open port 25 to the FTP server IP only, and port 80/443 to
> the web server only.
>
> The current rules are confusing for a new user with networking background.
> You have to understand that when selecting "Ingress" your specified CIDR is
> a *source* but when specifying "Egress" it is the destination CIDR.
>
> Thanks for the consideration,
>
> Christopher Falk
> Director, Technical Operations
> www.reliablenetworks.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message