incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jayapal Reddy Uradi <jayapalreddy.ur...@citrix.com>
Subject RE: StaticNAT, Portforwarding and FIrewall implemenation on the SRX
Date Thu, 18 Oct 2012 05:27:33 GMT
Hi Sangeetha,

Once concern in doing that is effect on existing deployments.

Thanks,
Jayapal



> -----Original Message-----
> From: Sangeetha Hariharan
> Sent: Wednesday, October 17, 2012 10:56 PM
> To: Jayapal Reddy Uradi; cloudstack-dev@incubator.apache.org; Alena
> Prokharchyk
> Subject: RE: StaticNAT, Portforwarding and FIrewall implemenation on the
> SRX
>
> Hi Jayapal,
>
> In SRX , we do not support firewall except in cases where we have to open
> the ports for Static NAT.
>
> This being the case , On any acquired Ip address which does NOT have a static
> NAT rule enabled, when user tries to open up a firewall , API should error
> out. There should be no entry for this firewall in the DB.
>
> In this assumption , the only case we will not be able support is the case
> where the user creates  firewall and then enables static NAT. But we can
> gracefully handle the failure situations where the firewall rules is created
> before or after a PF rule creation , by reporting back the error to the user.
>
> -Thanks
> Sangeetha
>
> -----Original Message-----
> From: Jayapal Reddy Uradi
> Sent: Tuesday, October 16, 2012 11:13 PM
> To: Sangeetha Hariharan; cloudstack-dev@incubator.apache.org
> Subject: RE: StaticNAT, Portforwarding and FIrewall implemenation on the
> SRX
>
> Hi Sangeetha,
>
> Please see my comments inline.
>
> Thanks,
> Jayapal
>
> > -----Original Message-----
> > From: Sangeetha Hariharan
> > Sent: Wednesday, October 17, 2012 4:35 AM
> > To: cloudstack-dev@incubator.apache.org; Jayapal Reddy Uradi
> > Subject: RE: StaticNAT, Portforwarding and FIrewall implemenation on
> > the SRX
> >
> > Jayapal,
> >
> > I had another question regarding the UI implementation:
> >
> > In UI Changes section , following is mentioned:
> >
> > "The following changes are needed for the networks page for the
> > external device SRX network.
> >
> > 1. Network ->Guest Network ->View IP Addresses -> <IP Address> ->
> > Configuration
> >
> > a. Hide the Firewall when Port forwarding is configured on IP Address."
> >
> > >> How do we prevent the case when the user creates a firewall first
> > >> and
> > then he tries to create a PF/LB rule (when we use SRX/F5 inline mode)
> > ? In this case what should be the expected behavior? Do we actually
> > configure the user created firewall , PF rule and also create
> > firewalls for the PF rule (if the port used in the create firewall is
> > different from that provided in the PF
> > rule) ?
> >
> 1. When user configured Firewall first then PF. Only PF rules are programed
> on the SRX.
>     Firewall rules are in DB but  ignored by SRX.
> 2. In UI  disable the Firewall  for the Public IP after configuring PF.
>
>
> > Thanks
> > Sangeetha
> >
> > -----Original Message-----
> > From: Sangeetha Hariharan
> > Sent: Tuesday, October 16, 2012 1:47 PM
> > To: cloudstack-dev@incubator.apache.org; Alena Prokharchyk
> > Subject: RE: StaticNAT, Portforwarding and FIrewall implemenation on
> > the SRX
> >
> > Hi Jayapal,
> >
> > Had the following questions after reviewing the FS.
> >
> >
> > 1) "Case 4:
> > Firewall rule is not deleted when disable the Static NAT.
> > 1. Acquire Ip P4.
> > 2. Create Firewall for port 22.
> > 3. Enable static NAT on P2 for VM2.
> > 4. Disable static NAT.
> > 5. Enable static NAT
> > 7.PublicNetwork# ssh <P4> (ssh to VM1 should success)"
> >
> > In this case, step 3 , i assume should be P4.
> >
> > After Step4 , In the SRX side , we will see both the firewall rule and
> > static NAT being deleted. But in cloud DB we will still have the
> > firewall rules present. Is this correct?
> >
> > After Step5 , In the SRX side , we will see both the firewall rule and
> > static NAT being created back in SRX side. Is this correct?
> >
> > 2) What will the behavior in the following use case where user deletes
> > a firewall that was created for a Static NAT rule ?
> >
> > 1. Acquire Ip address.
> > 2. Create an Static NAT rule.
> > 3. Create Firewall rules for port 22.
> > 4. Create Firewall rule for port 80.
> > 5. Delete firewall rule for port 22.
> > 6. Delete firewall rule for port 80.
> > 7. Add firewall rule for port 22.
> >
> > After Step 5 ,
> > In SRX , we expect the firewall rule for port 22 to be deleted.
> >
> > After Step 6 ,
> >
> > In SRX , Do we expect the firewall rule for port 80 and Static NAT
> > rule to be deleted ?
> >
> > After Step 7 ,
> >
> > In SRX , Do we expect the firewall rule for port 22 and Static NAT
> > rule to be created ?
> >
> > -Thanks
> > Sangeetha
> >
> > -----Original Message-----
> > From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
> > Sent: Tuesday, October 16, 2012 7:43 AM
> > To: cloudstack-dev@incubator.apache.org; Alena Prokharchyk
> > Subject: RE: StaticNAT, Portforwarding and FIrewall implemenation on
> > the SRX
> >
> > Updated the FS as per the discussion.
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Static+NAT,+Por
> > t+Forwarding+and+Firewall+Implementation+on+SRX
> >
> >
> > Thanks,
> > Jayapal
> >
> > > -----Original Message-----
> > > From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
> > > Sent: Tuesday, October 16, 2012 12:44 PM
> > > To: Alena Prokharchyk; cloudstack-dev@incubator.apache.org
> > > Subject: RE: StaticNAT, Portforwarding and FIrewall implemenation on
> > > the SRX
> > >
> > > Please see my comments inline.
> > >
> > > -Jayapal
> > >
> > > From: Alena Prokharchyk
> > > Sent: Monday, October 15, 2012 10:04 PM
> > > To: Jayapal Reddy Uradi; cloudstack-dev@incubator.apache.org
> > > Subject: Re: StaticNAT, Portforwarding and FIrewall implemenation on
> > > the SRX
> > >
> > >
> > >
> > > From: Jayapal Reddy Uradi
> > > <jayapalreddy.uradi@citrix.com<mailto:jayapalreddy.uradi@citrix.com>
> > > >
> > > To: Alena Prokharchyk
> > > <alena.prokharchyk@citrix.com<mailto:alena.prokharchyk@citrix.com>>,
> > > "cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> > > dev@incubator.apache.org>" <cloudstack-
> > > dev@incubator.apache.org<mailto:cloudstack-
> > dev@incubator.apache.org>>
> > > Subject: RE: StaticNAT, Portforwarding and FIrewall implemenation on
> > > the SRX
> > >
> > > Hi Alena,
> > >
> > > Please see my comments inline,
> > >
> > > -Jayapal
> > >
> > > -----Original Message-----
> > > From: Alena Prokharchyk
> > > Sent: Friday, October 12, 2012 10:19 PM
> > > To: Jayapal Reddy Uradi; cloudstack-
> > > dev@incubator.apache.org<mailto:cloudstack-
> dev@incubator.apache.org>
> > > Subject: Re: StaticNAT, Portforwarding and FIrewall implemenation on
> > > the SRX Jayapal, please see my comments inline.
> > > -Alena.
> > > On 10/11/12 11:07 PM, "Jayapal Reddy Uradi"
> > > <jayapalreddy.uradi@citrix.com<mailto:jayapalreddy.uradi@citrix.com>
> > > >
> > > wrote:
> > > >Alena,
> > > >
> > > >Please find my inline comments.
> > > >
> > > >Thanks,
> > > >Jayapal
> > > >
> > > >Thanks,
> > > >Jayapal
> > > >
> > > >-----Original Message-----
> > > >From: Alena Prokharchyk
> > > >Sent: Friday, October 12, 2012 5:54 AM
> > > >To:
> > > >cloudstack-dev@incubator.apache.org<mailto:cloudstack-
> > > dev@incubator.apa
> > > >che.org>; Jayapal Reddy Uradi
> > > >Subject: Re: StaticNAT, Portforwarding and FIrewall implemenation
> > > >on the SRX
> > > >
> > > >Jayapal, I reviewed the spec. My comments:
> > > >
> > > >If firewall rules per public IP address can't be configured on the
> > > >SRX, and there is no way to fix it (your spec says so in "Limitation"
> > > >section), why do we introduce all this complexity? To me it seems
> > > >like we are trying to show the user that he is controlling public
> > > >ports on SRX, while in fact it's not true. It should work just like
> > > >it used to work
> > > >before: the Ingress traffic flow from public to guest interfaces
> > > >should be controlled by PF/StaticNat/LB rule; Ingress traffic to
> > > >public ip address is allowed always. When there is no
> > > >PF/LB/StaticNat rule for the Guest network port, the traffic to
> > > >Guest port is blocked. Once you create PF rule for publicIp
> > > >+ guestIp, the access to the specific port of the Guest network is
> > > >+ opened
> > > >automatically. The example below (taken from the spec):
> > > >
> > > >Example:
> > > >
> > > >1. Acquire IP P1.
> > > >2. Create Firewall for port 22 - port 22.
> > > >3. Configure the port forwarding for Public IP P1, user VM V1 4.
> > > >Acquire another IP P2.
> > > >5. Enable staticNAT on P2 for VM V1
> > > >
> > > >//Jayapal
> > > >Let me change the  case here  and going to update in FS.
> > > >6.Add firewall rule for P2 for VM V1 on ports 80 7. Now In SRX,
> > > >using
> > > >P2  user can access the VM V1 ports 22 and 80.
> > > Still doesn't work like the regular Firewall rule. You enabled
> > > Firewall for port
> > > 22 on P1, and for port 80 on P2 and it results in being able to
> > > access port 22/80 on P2? Firewall rule on one public IP should never
> > > affect the behavior of another public IP. That's not how Firewall
> > > rule is supposed
> > to work.
> > > >
> > > >7. Now P1 and P2 both can access the VM port 22 - /// you haven't
> > > >created the Firewall rule for the P2, yet the access from it is
> > > >enabled implicitly to 22:22 port. It's very confusing. In other
> > > >words, the firewall rule created for P1 ip should never ever
> > > >control the access to
> > > >P2 ip address.
> > > >
> > > >
> > > >We need to fix the original issue - make StaticNat rules on the SRX.
> > > >For that we have to treat firewall rule as a static nat rule for a
> > > >particular port by SRX device if the static nat is enabled for this
> > > >public ip address in the cloudStack. In all other cases Firewall
> > > >rule should be just ignored.
> > > >
> > > >//Jayapal
> > > >I agree with ignoring firewall for port forwarding.
> > > >But in VR the PF rule works only after adding  Firewall rule for
> > > >the public ports.
> > > It is ok to leave it the old way for the SRX. Your limitation
> > > clearly says that you can't control the public IP / ports on the SRX anyway.
> > > So lets just fix the Static nat rule; it would also leave less
> > > chance for regressing in PF rules functionality.
> > > >
> > > >CASE1:
> > > >
> > > >* Get Ip1.
> > > >* Create PF rule for IP1 and port 22 VM1. Now you can access the Vm1.
> > > >* Create firewall rule for Ip1. SRX should just ignore this request
> > > >as it will not do anything
> > > >
> > > >
> > > >CASE2:
> > > >
> > > >* Get IP2
> > > >* Enable static nat on the IP2 and VM1. Nothing is sent to SRX just yet.
> > > >* Create firewall rule for IP2 and ports 22-23. Send enable static
> > > >nat for
> > > >IP2/VM1 and port 22-23 to the SRX device
> > > >* Repeat last step for each port (port range) you want to enable
> > > >static nat for.
> > > >
> > > >//Jayapal
> > > >In SRX,  below issue can still exist.
> > > >Case3:
> > > >In addition to CASE1, CASE2,  Create another PF rule for IP1 and
> > > >port
> > > >80 VM1. Now you can access the Vm1 port 80.
> > > >Now P2 can access the port 80 without Firewall rule on Port 80.
> > > >Because security policy in SRX  is not differentiated for Public IPs.
> > > You can never create the PF or LB rule for the ip address that has
> > > Static nat rule assigned.
> > > [Jayapal]
> > > But we can create
> > > -  PF:  P1, VM V1 and ports 22-22
> > > - Static NAT:  P2 VM V1, and Firewall port 80 Here P2 can access
> > > V1's ports 22, 80. This is specific to SRX.
> > >
> > > If it was always the case for SRX, then we just have to document it.
> > > I believe even with the initial design you've proposed, it would
> > > have been
> > the case.
> > > You can't control public ports with Firewall rules.
> > > Please confirm.
> > > [Jayapal]
> > >  This case is always with the SRX.
> > >
> > > >
> > > >In other words, you have to make the translation of Firewall rule
> > > >of the cloudStack to ConfigureStaticNat on SRX when the targeted
> > > >public IP address is Static nat enabled. In all other cases
> > > >Firewall commands should be just ignored by the SRX device.
> > > >
> > > >
> > > >Let me know what you think,
> > > >//Jayapal
> > > >I agree with you.
> > > >Current port forwarding rule have Public Port range and Private
> > > >Port range.
> > > >So port forwarding allows only the Public Ports that we added.
> > > >Again allowing Ports using Firewall is of no use.
> > > >Example:
> > > >Port forwarding rule: public Ports 22 and private ports 22 Here
> > > >Port Forwarding  can allow  only 22. so no need to explicitly add
> > > >using the firewall to allow If you donĀ¹t want to allow the ports
> > > >DELETE the Port Forwarding rule.
> > > >On top of PF  adding Firewall rule to allow ports 22-80 of no use
> > > >because there is port forwarding rule for 23-80.
> > > It's allright. We can change the UI to disable Firewall rule block
> > > on the networking diagram (when the PF provider is SRX). So only
> > > PF/LB and Static nat functionality will be enabled. For opening
> > > ports for static nat the UI will still be using createFirewall rule
> > > calls, but it will not be shown to the user as "Firewall"
> > > >
> > > >-Alena.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >On 10/11/12 6:16 AM, "Jayapal Reddy Uradi"
> > > ><jayapalreddy.uradi@citrix.com<mailto:jayapalreddy.uradi@citrix.com
> > > >>>
> > > >wrote:
> > > >
> > > >>StaticNAT,  PortForwarding  and Firewall  current functionality in
> > > >>SRX is not similar to the  Virtual router.
> > > >>This functional spec describes  the what  configuration possible
> > > >>on the SRX and also the limitation of SRX  compared to the
> > > >>functionality in
> > VR.
> > > >>
> > > >>Please find the functional spec here:
> > >
> >
> >>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Static+NAT,+P
> > > or
> > > >>t
> > > >>+Fo
> > > >>rwarding+and+Firewall+Implementation+on+SRX
> > > >>
> > > >>Please provide your comments on configuring the SRX device to get
> > > >>functionality  similar to  VR.
> > > >>
> > > >>Thanks,
> > > >>Jayapal
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >


Mime
View raw message