I am updating egress firewall rules FS with the createNetworkACL. Thanks, Jayapal
> -----Original Message----- > From: Alena Prokharchyk [mailto:alena.prokharc...@citrix.com] > Sent: Tuesday, October 16, 2012 10:28 PM > To: cloudstack-dev@incubator.apache.org; Anthony Xu > Subject: Re: Egress firewall rules for guest network. > > > 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+fire > >> >>>w > >> 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. > >> > > >> > > >> > > >> > > > > >
