cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <sh...@yasker.org>
Subject Re: Supported Source NAT Type?
Date Wed, 08 May 2013 22:18:23 GMT
The code looks fine to me. Looking forward to your repo!

--Sheng


On Wed, May 8, 2013 at 3:12 PM, Will Stevens <wstevens@cloudops.com> wrote:

> Alright, I have updated the code to what I have pasted at the bottom.  I
> have tested it and it is working as expected.  With this change I now have
> multiple networks per account working with my external firewall device.
>
> I will be posting my code to a public repo soon so people can start
> checking it out.
>
> Thanks for confirming this was legacy.
>
> Cheers,
>
> Will
>
> ---
>
> IPAddressVO sourceNatIp = null;
> if (!sharedSourceNat) {
>     // Get the source NAT IP address for this network
>     List<? extends IpAddress> sourceNatIps =
> _networkModel.listPublicIpsAssignedToAccount(network.getAccountId(),
> zoneId, true);
>
>     for (IpAddress ipAddress : sourceNatIps) {
>         if (ipAddress.getAssociatedWithNetworkId().longValue() ==
> network.getId()) {
>             sourceNatIp = _ipAddressDao.findById(ipAddress.getId());
>             break;
>         }
>     }
>     if (sourceNatIp == null) {
>         String errorMsg = "External firewall was unable to find the source
> NAT IP address for network " + network.getName();
>         s_logger.error(errorMsg);
>         return true;
>     }
> }
>
>
>
>
> On Wed, May 8, 2013 at 5:21 PM, Sheng Yang <sheng@yasker.org> wrote:
>
> > 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 <wstevens@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 <wstevens@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 <sheng@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 <
> wstevens@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 <sheng@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 <
> > > wstevens@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.childers@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
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message