Re: Firewall rule question
On Wed, May 15, 2013 at 05:54:36AM +, 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
Re: Firewall rule question
On Wed, May 15, 2013 at 06:43:44AM +, Koushik Das wrote: 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. Sorry, don't mean to hijack this thread: But I'm not sure of the flexibility you speak of, is it given to the tenant? If I was a tenant using a network offering using the VR and had programmed my FW rules accordingly. On upgrading my network offering to say, a PaloAlto FW, if all my instances suddenly become unreachable, I don't see that as favourable behaviour. -- Prasanna., Powered by BigRock.com
RE: Firewall rule question
-Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Wednesday, May 15, 2013 12:25 PM To: dev@cloudstack.apache.org Subject: Re: Firewall rule question On Wed, May 15, 2013 at 06:43:44AM +, Koushik Das wrote: 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. Sorry, don't mean to hijack this thread: But I'm not sure of the flexibility you speak of, is it given to the tenant? If I was a tenant using a network offering using the VR and had programmed my FW rules accordingly. On upgrading my network offering to say, a PaloAlto FW, if all my instances suddenly become unreachable, I don't see that as favourable behaviour. The tenant will have flexibility to select network offering but the admin will decide what all offerings to provide based on Capabilities/limitations etc. Let's take the e.g. of VR and PaloAlto as firewall service provider. Currently the framework allows certain type of firewall rules which works with VR provider. Now say PaloAlto is more restrictive and in order to accommodate it more validations are added in the framework. The use case you have mentioned above is still broken for existing networks. When there are varied external devices, it's a difficult problem to arrive at a common validation layer. It's possible that every time a new device is integrated you may find the validations too restrictive or too flexible. -- Prasanna., Powered by BigRock.com
Re: Firewall rule question
I'm with Prasanna here, the behavioral inconsistency is baffling. How would we document the differentiation at the api level? On Wed, May 15, 2013 at 12:34 AM, Koushik Das koushik@citrix.comwrote: -Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Wednesday, May 15, 2013 12:25 PM To: dev@cloudstack.apache.org Subject: Re: Firewall rule question On Wed, May 15, 2013 at 06:43:44AM +, Koushik Das wrote: 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. Sorry, don't mean to hijack this thread: But I'm not sure of the flexibility you speak of, is it given to the tenant? If I was a tenant using a network offering using the VR and had programmed my FW rules accordingly. On upgrading my network offering to say, a PaloAlto FW, if all my instances suddenly become unreachable, I don't see that as favourable behaviour. The tenant will have flexibility to select network offering but the admin will decide what all offerings to provide based on Capabilities/limitations etc. Let's take the e.g. of VR and PaloAlto as firewall service provider. Currently the framework allows certain type of firewall rules which works with VR provider. Now say PaloAlto is more restrictive and in order to accommodate it more validations are added in the framework. The use case you have mentioned above is still broken for existing networks. When there are varied external devices, it's a difficult problem to arrive at a common validation layer. It's possible that every time a new device is integrated you may find the validations too restrictive or too flexible. -- Prasanna., Powered by BigRock.com
Re: Firewall rule question
I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
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. On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
RE: Firewall rule question
For the createFirewallRule and createEgressFirewallRule APIs the port parameters are optional. If you don't specify the port range for the prototocol (TCP) it allows all the tcp traffic. Ingress: 1. First firewall rules filters traffic then PF/Static NAT will NAT to the specific VM. If you specify tcp with out ports all tcp traffic on IP is allowed then PF/Static NAT rule (PF ports) decides to which VM the traffic should be NATed. Egress: Traffic from guest network to public network is filtered by egress. If you specify the tcp with out ports all egress tcp traffic is allowed. Thanks, Jayapal -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Wednesday, 15 May 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. On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
Re: Firewall rule question
understood. I assume this is the documented (in a FS or some such design doc) behavior, correct? Thanks for the prompt reply Jaypal! On Tue, May 14, 2013 at 9:58 PM, Jayapal Reddy Uradi jayapalreddy.ur...@citrix.com wrote: For the createFirewallRule and createEgressFirewallRule APIs the port parameters are optional. If you don't specify the port range for the prototocol (TCP) it allows all the tcp traffic. Ingress: 1. First firewall rules filters traffic then PF/Static NAT will NAT to the specific VM. If you specify tcp with out ports all tcp traffic on IP is allowed then PF/Static NAT rule (PF ports) decides to which VM the traffic should be NATed. Egress: Traffic from guest network to public network is filtered by egress. If you specify the tcp with out ports all egress tcp traffic is allowed. Thanks, Jayapal -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Wednesday, 15 May 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. On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
RE: Firewall rule question
-Original Message- From: Jayapal Reddy Uradi [mailto:jayapalreddy.ur...@citrix.com] Sent: Wednesday, May 15, 2013 10:29 AM To: dev@cloudstack.apache.org; aemne...@gmail.com Subject: RE: Firewall rule question For the createFirewallRule and createEgressFirewallRule APIs the port parameters are optional. If you don't specify the port range for the prototocol (TCP) it allows all the tcp traffic. Ingress: 1. First firewall rules filters traffic then PF/Static NAT will NAT to the specific VM. If you specify tcp with out ports all tcp traffic on IP is allowed then PF/Static NAT rule (PF ports) decides to which VM the traffic should be NATed. Egress: Traffic from guest network to public network is filtered by egress. If you specify the tcp with out ports all egress tcp traffic is allowed. In case of egress even the cidr is optional. If nothing is specified it defaults to the guest network cidr. Thanks, Jayapal -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Wednesday, 15 May 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. On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
RE: Firewall rule question
-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) On Tue, May 14, 2013 at 2:41 PM, Ahmad Emneina aemne...@gmail.com wrote: I'm hoping thats not the default behavior, and nothing happens on the firewall. I guess the fact that empty values entered returns success is a bug? On Tue, May 14, 2013 at 8:00 AM, Will Stevens wstev...@cloudops.com wrote: This applies to both Egress firewall rules as well as IP specific firewall rules. If you specify TCP but do not specify any port details, it saves fine. I am wondering what this config implies. Does this mean that all TCP traffic is allowed? Thanks, Will
