Prasanna, Interesting point. On one hand there is consistency and on the other hand flexibility. Not sure if the framework should be restrictive or as flexible as possible but I personally like the latter option.
> -----Original Message----- > From: Prasanna Santhanam [mailto:t...@apache.org] > Sent: Wednesday, May 15, 2013 11:54 AM > To: dev@cloudstack.apache.org > Subject: Re: Firewall rule question > > On Wed, May 15, 2013 at 05:54:36AM +0000, Koushik Das wrote: > > > > > > > -----Original Message----- > > > From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On > > > Behalf Of Will Stevens > > > Sent: Wednesday, May 15, 2013 12:19 AM > > > To: dev@cloudstack.apache.org; aemne...@gmail.com > > > Subject: Re: Firewall rule question > > > > > > Ya, I am not sure. I am working off a master branch from about 2-3 > > > weeks ago. I was kind of expecting it to error and it didn't, so it > > > was not clear how that case would behave. I am currently developing > > > an integration with the Palo Alto firewall and they don't support > > > specifying a protocol like TCP without any port information. I > > > still have to finalize the logic associated with that edge case, so > > > I wanted to understand what the expected behaviour was from that > config. > > > > > > > I recently did the Cisco ASA firewall integration and there it is allowed to > create a firewall rule with TCP without specifying any port information. > > I think you can either do one of the following: > > - Block it if Palo Alto firewall doesn't allow creation of TCP rule > > without port information OR > > - Create a rule with all possible port ranges (min and max port > > values) > > > That makes it inconsistent and counter-intuitive to the tenant who is aware > of only the API. If one set of FW rules block and other using the external > device allows or vice versa. > > IMO - ingress FW should just block until no ports are specified. Seems more > sane to do that. > > -- > Prasanna., > > ------------------------ > Powered by BigRock.com
