I've checked the code and seems it's legacy code here. SRX's support for
"per account" is broken anyway, so you can modify it according to your
requirement.

Multiple networks per account for external devices is really nice to have,
I think you can go ahead and implement it.

Thanks.

--Sheng

On Wed, May 8, 2013 at 1:25 PM, Will Stevens <wstev...@cloudops.com> wrote:

> I am trying to use the 'per account' source nat type in the network
> offering for my Palo Alto Firewall integration.  I currently have it
> working for one network per account.  Obviously I would like to support
> more than one network per account.  I am not sure that this functionality
> is currently implemented.
>
> Here is the code in question in ExternalFirewallDeviceManagerImpl.java and
> function 'manageGuestNetworkWithExternalFirewall':
> IPAddressVO sourceNatIp = null;
> if (!sharedSourceNat) {
>     // Get the source NAT IP address for this account
>     List<? extends IpAddress> sourceNatIps =
> _networkModel.listPublicIpsAssignedToAccount(network.getAccountId(),
>             zoneId, true);
>
>     if (sourceNatIps.size() != 1) {
>         String errorMsg = "External firewall was unable to find the source
> NAT IP address for account "
>     + account.getAccountName();
>         s_logger.error(errorMsg);
>         return true;
>     } else {
>         sourceNatIp = _ipAddressDao.findById(sourceNatIps.get(0).getId());
>     }
> }
>
> This piece of code is supposed to handle the when the source nat type is
> 'per account' instead of 'per zone'.  This clearly only supports one
> network per account.
>
> Since the condition when 'sourceNatIps.size() != 1' is only an error, would
> I have the go ahead to implement support for multiple networks in one
> account or am I missing something here?  Basically, I will want to set the
> 'sourceNatIp' variable to be the source nat ip for the specific network.
>
> Let me know what you think...
>
> Thanks,
>
> Will
>
>
>
>
>
> On Thu, Apr 18, 2013 at 6:28 PM, Will Stevens <wstev...@cloudops.com>
> wrote:
>
> > Great.  Thanks again, this is very helpful.
> >
> > So the way I am doing it is good for now.  If IP space becomes an issue
> > (when people are actually using it), I could implement the 'per zone'
> > approach as well.
> >
> > In the per zone approach, the firewall would be initially configured with
> > a public IP and a generic source nat rule which would map the entire
> guest
> > network range in the trusted zone to the preconfigured public IP in the
> > untrusted zone.  I understand how this works now and why the source nat
> > rules will not need to be managed by cloudstack.
> >
> > Thanks again for the explanation.
> >
> >
> > On Thu, Apr 18, 2013 at 6:12 PM, Sheng Yang <sh...@yasker.org> wrote:
> >
> >> Hi Will,
> >>
> >> "per account" is perfectly fine in your case. "per zone" can be used if
> >> user want to preserve some public IPs. And with "per zone", CloudStack
> >> just
> >> won't care about source nat ip allocation etc any more, it would assume
> >> that the firewall should already has taken care of that. Source NAT IP
> >> would be blank in Cloudstack(a.k.a. isolated network without source nat
> >> ip).
> >>
> >> It's not requirement to support "per zone". In fact as long as your
> device
> >> can support of the source nat mechanism then it's fine. But I don't
> think
> >> you need to handle source nat rules if you use "per zone" mode(from CS's
> >> perspective). E.g. Juniper SRX has such a configuration:
> >>
> >>     nat {
> >>         source {
> >>             pool inat-pool {
> >>                 address {
> >>                     10.223.161.18/32;
> >>                 }
> >>             }
> >>             rule-set trust {
> >>                 from zone trust;
> >>                 to zone untrust;
> >>                 rule i-nat {
> >>                     match {
> >>                         source-address 10.0.0.0/8;
> >>                     }
> >>                     then {
> >>                         source-nat {
> >>                             pool {
> >>                                 inat-pool;
> >>                             }
> >>                         }
> >>                     }
> >>                 }
> >>             }
> >>         }
> >>     }
> >>
> >> This one would fit all traffic from "trust" zone(every newly created
> >> isolated network would be in trust zone) to "untrust" zone(public
> >> network),
> >> using source nat.
> >>
> >> --Sheng
> >>
> >> On Thu, Apr 18, 2013 at 2:50 PM, Will Stevens <wstev...@cloudops.com>
> >> wrote:
> >>
> >> > Thanks for the answer Sheng.
> >> >
> >> > I currently have the Palo Alto firewall using the 'per account' method
> >> and
> >> > when 'IpAssocCommand' is run (when the first VM is added to a palo
> alto
> >> > network ), I am dynamically creating a public sub-interface and
> >> assigning a
> >> > public IP (provided by cloudstack).  I am also creating a private
> >> > sub-interface on the PA which I am using the the gateway for the CS
> >> > network.  I am dynamically creating/deleting the SourceNat rules
> between
> >> > the two sub-interfaces (gateway/cidr# -> public_ip/32) on implement
> and
> >> > shutdown.
> >> >
> >> > In your eyes, is this the best way to handle this?  If I was to use
> the
> >> > 'per zone' option, how would the Source Nat IP get set in Cloudstack?
> >>  So
> >> > there would be one public IP per zone which all the public traffic
> >> would go
> >> > through for all networks?  I would still have to handle the source nat
> >> > rules from each CS network to that single public IP I believe.
> >> >
> >> > I am slowly getting this all documented at:
> >> >
> >> >
> >>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
> >> >
> >> > Thanks...
> >> >
> >> >
> >> > On Thu, Apr 18, 2013 at 5:19 PM, Sheng Yang <sh...@yasker.org> wrote:
> >> >
> >> > > Hi Will,
> >> > >
> >> > > "Per zone" is mostly for external network devices(e.g. SRX). We can
> >> > > configure one public network address on SRX, and use that one(which
> is
> >> > out
> >> > > of Cloudstack's control) for all the public traffic go through the
> >> > device.
> >> > > That's "Per zone".
> >> > >
> >> > > "Per account" is the other way, used by VR in CloudStack. It would
> >> > acquire
> >> > > one public ip from public ip pool in the zone for each isolated
> >> network,
> >> > > and make it source nat IP for the network. The name "per account"
> >> because
> >> > > in the past one user would have only one isolated network, so the
> >> network
> >> > > is de facto per account. It's not necessary true now, but the name
> >> > remained
> >> > > I think.
> >> > >
> >> > > There are probably bad names, we should get better name than them...
> >> > >
> >> > > --Sheng
> >> > >
> >> > >
> >> > > On Thu, Apr 18, 2013 at 2:07 PM, Will Stevens <
> wstev...@cloudops.com>
> >> > > wrote:
> >> > >
> >> > > > Oh, my bad.  I forgot about that.
> >> > > >
> >> > > > On the 'create network service offering' overlay, if you select
> >> > > 'SourceNat'
> >> > > > in Supported Services, there is a drop down which get added.  The
> >> drop
> >> > > down
> >> > > > has the title of 'Supported Source Nat Type' and has two options:
> >> 'Per
> >> > > > zone' and 'Per account'
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > Will
> >> > > >
> >> > > >
> >> > > > On Thu, Apr 18, 2013 at 4:09 PM, Chip Childers <
> >> > > chip.child...@sungard.com
> >> > > > >wrote:
> >> > > >
> >> > > > > Will,
> >> > > > >
> >> > > > > Images and other attachments are stripped on this list (text
> only
> >> > > > > please!)
> >> > > > >
> >> > > > > Can you post the image somewhere or describe the list?
> >> > > > >
> >> > > > > On Thu, Apr 18, 2013 at 04:05:36PM -0400, Will Stevens wrote:
> >> > > > > > In the 'Create network service offering' flow there is this
> >> > dropdown:
> >> > > > > >
> >> > > > > > [image: Inline image 1]
> >> > > > > >
> >> > > > > > What are the implications for picking one or the other?
> >> > > > > >
> >> > > > > > This code seems related in
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> 'com.cloud.network.ExternalFirewallDeviceManagerImpl.manageGuestNetworkWithExternalFirewall()'
> >> > > > > > :
> >> > > > > > NetworkOffering offering =
> >> > > > > > _networkOfferingDao.findById(network.getNetworkOfferingId());
> >> > > > > > boolean sharedSourceNat = offering.getSharedSourceNat();
> >> > > > > >
> >> > > > > > IPAddressVO sourceNatIp = null;
> >> > > > > > if (!sharedSourceNat) {
> >> > > > > >     // Get the source NAT IP address for this account
> >> > > > > >     List<? extends IpAddress> sourceNatIps =
> >> > > > > >
> >> _networkMgr.listPublicIpsAssignedToAccount(network.getAccountId(),
> >> > > > > >             zoneId, true);
> >> > > > > >
> >> > > > > >     if (sourceNatIps.size() != 1) {
> >> > > > > >         String errorMsg = "External firewall was unable to
> find
> >> the
> >> > > > > source
> >> > > > > > NAT IP address for account "
> >> > > > > >     + account.getAccountName();
> >> > > > > >         s_logger.error(errorMsg);
> >> > > > > >         return true;
> >> > > > > >     } else {
> >> > > > > >         sourceNatIp =
> >> > > > > _ipAddressDao.findById(sourceNatIps.get(0).getId());
> >> > > > > >     }
> >> > > > > > }
> >> > > > > >
> >> > > > > > How does the 'sourceNatIp' get set if 'sharedSourceNat' is
> true?
> >> > > > > >
> >> > > > > > Thanks,
> >> > > > > >
> >> > > > > > Will
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Reply via email to