You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Will Stevens <ws...@cloudops.com> on 2013/05/14 17:00:01 UTC
Firewall rule question
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
Posted by Koushik Das <ko...@citrix.com>.
> -----Original Message-----
> From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
> Sent: Wednesday, May 15, 2013 10:29 AM
> To: dev@cloudstack.apache.org; aemneina@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: williamstevens@gmail.com [mailto:williamstevens@gmail.com] On
> > Behalf Of Will Stevens
> > Sent: Wednesday, 15 May 2013 12:19 AM
> > To: dev@cloudstack.apache.org; aemneina@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 <ae...@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
> > > <ws...@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
Posted by Ahmad Emneina <ae...@gmail.com>.
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.uradi@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: williamstevens@gmail.com [mailto:williamstevens@gmail.com] On
> > Behalf Of Will Stevens
> > Sent: Wednesday, 15 May 2013 12:19 AM
> > To: dev@cloudstack.apache.org; aemneina@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 <ae...@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 <ws...@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
Posted by Jayapal Reddy Uradi <ja...@citrix.com>.
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: williamstevens@gmail.com [mailto:williamstevens@gmail.com] On
> Behalf Of Will Stevens
> Sent: Wednesday, 15 May 2013 12:19 AM
> To: dev@cloudstack.apache.org; aemneina@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 <ae...@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 <ws...@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
Posted by Ahmad Emneina <ae...@gmail.com>.
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 <ko...@citrix.com>wrote:
>
>
> > -----Original Message-----
> > From: Prasanna Santhanam [mailto:tsp@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 +0000, 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
Posted by Koushik Das <ko...@citrix.com>.
> -----Original Message-----
> From: Prasanna Santhanam [mailto:tsp@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 +0000, 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
Posted by Prasanna Santhanam <ts...@apache.org>.
On Wed, May 15, 2013 at 06:43:44AM +0000, 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
Posted by Koushik Das <ko...@citrix.com>.
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:tsp@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: williamstevens@gmail.com [mailto:williamstevens@gmail.com] On
> > > Behalf Of Will Stevens
> > > Sent: Wednesday, May 15, 2013 12:19 AM
> > > To: dev@cloudstack.apache.org; aemneina@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
Posted by Prasanna Santhanam <ts...@apache.org>.
On Wed, May 15, 2013 at 05:54:36AM +0000, Koushik Das wrote:
>
>
> > -----Original Message-----
> > From: williamstevens@gmail.com [mailto:williamstevens@gmail.com] On
> > Behalf Of Will Stevens
> > Sent: Wednesday, May 15, 2013 12:19 AM
> > To: dev@cloudstack.apache.org; aemneina@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
Posted by Koushik Das <ko...@citrix.com>.
> -----Original Message-----
> From: williamstevens@gmail.com [mailto:williamstevens@gmail.com] On
> Behalf Of Will Stevens
> Sent: Wednesday, May 15, 2013 12:19 AM
> To: dev@cloudstack.apache.org; aemneina@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 <ae...@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 <ws...@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
Posted by Will Stevens <ws...@cloudops.com>.
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 <ae...@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 <ws...@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
Posted by Ahmad Emneina <ae...@gmail.com>.
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 <ws...@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
>