Though CreateNetworkACL and CreateFirewallRule APIs are configuring the
firewall rules, but there is difference in the purpose for which it is used.
CreateNetworkACL - API is used for configuring firewall rules
per Network.
CreateFirewallRule - API is used for configuring firewall rules
per public IP.
Thanks,
Jayapal
Thanks,
Jayapal
> -----Original Message-----
> From: Anthony Xu
> Sent: Monday, October 15, 2012 6:38 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: Jayapal Reddy Uradi
> Subject: RE: Egress firewall rules for guest network.
>
> > We need to understand how network ACL rules are different from
> >Firewall rules. The difference comes about when you look at the
> >stateful/stateless nature of traffic being shaped by the router. In
> >most networking parlance I have seen, network ACLs serve only stateless
> >behaviour. Firewalls can do stateful traffic filtering - ingress and
> >egress.
>
>
> 1. both firewall rule and network ACL rule are stateful. Stateful means rule
> only check new request , stateless means rule check both request and
> response.
> 2. firewall rule is against public IP, ACL is against guest network, it
> doesn't
> care which public IP it goes through
>
>
> -----Original Message-----
> From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
> Sent: Wednesday, October 10, 2012 9:44 AM
> To: cloudstack-dev@incubator.apache.org
> Cc: Jayapal Reddy Uradi
> Subject: Re: Egress firewall rules for guest network.
>
> Hi Jayapal,
>
> See my comments below.
>
> -Alena.
>
> On 10/10/12 1:50 AM, "Jayapal Reddy Uradi"
> <jayapalreddy.ur...@citrix.com>
> wrote:
>
> >Hi Alena,
> >
> >I did evaluate both the options of using current network ACL
> >functionality to implement the egress firewall rules and enhance
> >CreateFirewall API to support both ingress and egress. If we go down
> >the path of implementing egress firewall with Network ACL it increases
> >the scope of the proposed changes to make behaviour consistent across
> APIs.
> >
> >1. First network ACL's implementation is hardcoded for VPC only.Network
> >ACL's implementation will have to be generalised first to support both
> >virtual router and VPC virtual router, and make it work for both VPC
> >networks and non-VPC networks.
>
> Easy to change. Just make VirtualNetworkRouterElement to implement
> NetworkACLServiceProvider. And move networkACL code from
> VpcVirtualRouterManager to virtualRouterManager.
>
>
> >2. Also currently while creating network offering, firewall and network
> >ACL's services are mutually exclusive which tells me that the purpose
> >of each is different.
>
> Artificial limitation. There is nothing on the backend preventing from
> applying
> network ACL and Firewall rules. As a part of the fix for that, add capability
> "trafficType" to the NetworkACL service. Regular VR will support Public
> capability (as you create the network ACL for public network only); in VPC is
> going to be Guest.
>
>
> > We need to understand how network ACL rules are different from
> >Firewall rules. The difference comes about when you look at the
> >stateful/stateless nature of traffic being shaped by the router. In
> >most networking parlance I have seen, network ACLs serve only stateless
> >behaviour. Firewalls can do stateful traffic filtering - ingress and
> >egress.
>
>
> Anthony Xu can help you to understand how its different as he did the
> scripting for the network ACL calls on the virtualRouter.
>
>
> >3. My final concern is the confusion coming about in the APIs and this
> >is the most important - If a user had to use createFirewallRule to
> >allow ingress traffic and then apply egress rules using a
> >createNetworkACL API it makes things inconsistent and unintuitive.
>
> But you are introducing some other confusion - before publicIPAddress was
> required for createFirewallRule and ingress rule was created for a specific
> IP;
> now you are dividing it to 2 paths - ingress per IP and ingress per network.
> The DB schema changes have to be made for that, the constructors for
> firewallRule have to be changed, etc.
>
> >
> >In summary - The scope of this change is limited to VR and SRX firewall
> >filtering. For guest networks right now it is a value-add to allow
> >filtering ingress /egress rules and simplify the view for the user.
> >Implementing ACLs will require a deeper change and rethink of our
> >current firewall/acl behaviour.
>
>
> I would still advise to go with networkACLs. The api calls already have all
> the
> parameters you need, all the backend logic is in place. Plus in the future we
> are planning to enhance the functionality by adding ALLOW/DENY
> permissions and Priority to the network ACLs.
>
> >
> >Thanks,
> >Jayapal
> >
> >-----Original Message-----
> >From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com]
> >Sent: Tuesday, October 09, 2012 10:43 PM
> >To: cloudstack-dev@incubator.apache.org
> >Subject: Re: Egress firewall rules for guest network.
> >
> >On 10/9/12 8:10 AM, "David Nalley" <da...@gnsa.us> wrote:
> >
> >>On Tue, Oct 9, 2012 at 5:14 AM, Jayapal Reddy Uradi
> >><jayapalreddy.ur...@citrix.com> wrote:
> >>> The egress firewall rules feature will configure the egress rules
> >>>for guest network on VR/External firewall to ALLOW
> >>>
> >>> specified traffic to outside and BLOCK the remaining traffic.
> >>>
> >>>
> >>>
> >>> By default all the traffic is ALLOWED to public network. When you
> >>>specify a egress rule only that rule specific traffic is allowed.
> >>>
> >>>
> >>>
> >>> I have created a functional spec here:
> >>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Egress+firew
> al
> >>>l
> >>>+ru
> >>>les+for+guest+network
> >>>
> >>>
> >>>
> >>> Please review and provide your comments.
> >>>
> >>> Thanks,
> >>> Jayapal
> >>
> >>
> >>So I noticed you are modifying createFirewallRule in a way which would
> >>break backwards compatibility, or at least make it more difficult.
> >>
> >>I'd suggest that trafficType be optional and default to to ingress -
> >>which means existing calls being issued today should continue to work
> >>as they do now, and folks wishing to take advantage of egress
> >>filtering can pass trafficType=egress for any calls. Is there any
> >>downside to doing it that way that I am missing?
> >>
> >>--David
> >>
> >
> >
> >Agree with David. This is a #1 API modification rule - never ever
> >introduce the required parameter to existing endUser API. Always make
> >it optional, and default it to some value if not specified but required
> >by the backend code.
> >
> >Jayapal, my other question is - why don't you use createNetworkACL
> >instead of createFirewallRule api? createFirewallRule api doesn't quite
> >fit here as it requires publicIpAddress to be passed in. The firewall
> >rule is always created per IP basis, not per network. While in
> >netowrkACL all you need to pass in - networkId and source/dest CIDR
> >(based on the traffic side). And accept id of the public/guest network as the
> networkId.
> >
> >I don't like the idea of splitting the logic for createFirewallRule to
> >a) create a rule for the entire network b) create a rule for a
> >particular publicIpAddress. So I advocate to use createNetworkACL as it
> >already has all the parameters you need + the backend implementation is
> >already in (for VPC case only by now, but should be pretty easy to
> >adopt by the regular virtual router).
> >
> >
> >
> >
> >-Alena.
> >
> >
> >
>
