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 > 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> 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; 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. > > > > >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> > >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 > >> > >> > > > > > > >
