Updated the Egress firewall rules FS. https://cwiki.apache.org/confluence/display/CLOUDSTACK/Egress+firewall+rules+for+guest+network
Thanks, Jayapal > -----Original Message----- > From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] > Sent: Wednesday, October 17, 2012 8:12 PM > To: cloudstack-dev@incubator.apache.org; Anthony Xu > Subject: RE: Egress firewall rules for guest network. > > 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. > > >> > > > >> > > > >> > > > >> > > > > > > > >
