You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Will Stevens <ws...@cloudops.com> on 2013/05/08 22:25:29 UTC

Re: Supported Source NAT Type?

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 <ws...@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 <ws...@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 <ws...@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
>> > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: Supported Source NAT Type?

Posted by Sheng Yang <sh...@yasker.org>.
The code looks fine to me. Looking forward to your repo!

--Sheng


On Wed, May 8, 2013 at 3:12 PM, Will Stevens <ws...@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 <sh...@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 <ws...@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 <ws...@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 <
> 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 <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 <
> > > 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
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>

Re: Supported Source NAT Type?

Posted by Will Stevens <ws...@cloudops.com>.
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 <sh...@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 <ws...@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 <ws...@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 <ws...@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 <
> > 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
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: Supported Source NAT Type?

Posted by Sheng Yang <sh...@yasker.org>.
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 <ws...@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 <ws...@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 <ws...@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 <
> 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
> >> > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>