On 10/16/12 8:34 AM, "Jayapal Reddy Uradi" <jayapalreddy.ur...@citrix.com> wrote:
> >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. Clarification - per guest network > CreateFirewallRule - API is used for configuring firewall >rules per public IP. Jayapal, if your goal is to control egress traffic on the guest network, you should use NetworkACL rule. > > >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. >> > >> > >> > >> > >
