Will, There is a mode in CloudStack that only allows non-intersecting cidrs for guest networks. It was introduced specifically because many physical network devices do not expect cidrs to intersect even when it's on different VLANs.
Sheng should be able to tell you how to get that to work. --Alex > -----Original Message----- > From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On > Behalf Of Will Stevens > Sent: Friday, March 15, 2013 1:16 PM > To: cloudstack-dev@incubator.apache.org > Subject: [DISCUSS] Palo Alto Integration > > As many of you know at this point, I am working to integrate the Palo Alto > firewall with CloudStack. > > More info here: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firew > all+Integration > > The problem I am running into right now is that Palo Alto does not allow any > two interfaced to have the same IP (even if they are in different zones, vrs, > vsys and vlans). This is an issue because CloudStack supports each account > having their own private IP ranges and two accounts can use the same > private IP range. For example, by default if you create a network with source > nat and you do not specify any gateway or subnet data, it will give you > 10.1.1.0/24 as an IP range. This means it will be very likely that two > CloudStack accounts will be using the same private IP space. > > I am trying to find a work around for this limitation, but so far I have been > having a hard time finding a reasonable solution. I have discussed this > problem with a few people and there have been a couple suggestions, but I > am not happy with these options: > > 1. Restrict the available subnets for each account so two accounts can't > create overlapping subnets. > To me, this breaks the whole concept of cloud, but for enterprise customers > this is not a huge limitation because they usually solve this problem this > way. > > 2. Run multiple Palo Alto VM firewalls and associate one VM firewall per > account. > The management overhead of this is crazy, so this type of implementation > would be very hard to work with. > > Since I do not like either of these approaches, I wanted to see if I could get > some feedback on this. Are there other alternatives that would solve the > problem more elegantly that I have not mentioned? What would be the best > way to solve this problem in a 'CloudStack way'? > > Any feedback on this would be appreciated. > > Cheers, > > Will
