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.ur...@citrix.com<mailto:jayapalreddy.ur...@citrix.com>> To: Alena Prokharchyk <alena.prokharc...@citrix.com<mailto:alena.prokharc...@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.ur...@citrix.com<mailto:jayapalreddy.ur...@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.apache.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.ur...@citrix.com<mailto:jayapalreddy.ur...@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 >> >> > > >
