We recently had a BIC consultant that was having problems with this deployment @ a PANW customer. The problem was due to confusion on the bucket structure for bootstrap deployment.

My suggestion is that we adjust the documentation in step 5 to reference back to the folder structure that we have documented elsewhere.

Either of these links would be helpful IMO

https://www.paloaltonetworks.com/documentation/81/virtualization/virtualization/bootstrap-the-vm-series-firewall/prepare-the-bootstrap-package

https://www.paloaltonetworks.com/documentation/81/virtualization/virtualization/bootstrap-the-vm-series-firewall/bootstrap-the-vm-series-firewall-in-aws

Or even just including a screenshot like the one that is attached.

Trying to look over this but it is a little over my head. We have purchased two VM instances instead of pay as you go. What would be required to tweak this solution to use those and only one instance per an availability zone in the transit VPC instead of two per an AZ .

Currently, a user has to manually enable route propagation on the subscriber VPC. Is it possible to have route propagation enabled by default when subscriber VPC is being instantiated or configured?

Can you walk me through how to set up the BGP redundancy on the Palo Alto? I am currently trying to deploy this in an unsupported region of AWS and therefore trying to reverse engineer the template, which is taking quite some time.

Thanks!

Hello,

I have run the InitializeTransitAccount and InitializeSubscriberAccount without issue (no VPC created). However, when adding subscribing VPC's, I am running into the following issues:

1. When subscribing an existing VPC using the tag, the firewalls get created (PaGroup58), but the VPN connections never get created. These firewalls are properly bootstrapped (PW from the deployment guide works).

2. When using the CFT to create a new VPC, a new set of firewalls gets built (PaGroup29), but again the VPN connections never get created. The new firewalls are NOT properly bootstrapped.

I had previously run the InitializeSubscriberAccount and created a VPC at the same time (option 8.1). This worked and created the VPN connections.

Could you provide information on how to fix this issue?

Currently, all new tunnels are added to the UNTRUST zone on the firewalls to which they are connected. There should be a new zone created per subscriber VPC and the tunnels for the new VPC connection added to the new zone. The zone name can be provided in the subscriber VPC CFT.

Hey,

We are testing this solution and everything is up and running fine. The only issue we have is how can we recover from a failed instance (Auto recovery is setup)?

We thought about ASG but then it gets complicated with elastic network interfaces.

Does anyone have a nice solution to redeploy a single instance? We already export the palo configs to the s3 bucket on a daily basis.

In the paGroupCft.json file, the default instance size is set to c4.xlarge. According to your list of configuration options included in the Firewall Bundle 2 subscription (url noted below), c4.xlarge is not listed. On execution of the stack, we received a similar error that the configuration was not supported. Manually changing the default instance type to m4.xlarge resolved the issue, however I felt it was worth a mention.

In order to use this AWS Marketplace product you need to accept terms and subscribe. To do so please visit http://aws.amazon.com/marketplace/pp?sku=806j2of0qy5osgjjixq9gqc6g

"The instance configuration for this AWS Marketplace product is not supported. Please see the AWS Marketplace site for more information about supported instance types, regions, and operating systems."

In the default deployment, the untrusted FW interface is given an EIP (obviously necessary) and an inbound ANY/ANY ALLOW security group is applied. This allows me to manage the FW via the web UI using the EIP. The FW itself notes the IP assigned to the MGMT interface (AWS eth0), but it doesn't seem to enforce that. Is this expected? What's the best way to lock down management to only the eth0 interface?

Hi! Completed the Transit VPC using the scripts working fine. However struggling to get a spoke VPC working in another account. I did the subscriber stack and it never spins up the VPNs In the secondary account. Are their any guides or at least gotchas when utilizing a VPC in a different account than the Tranist?
Thank you in advance for guidance

I used a non-default CIDR when deploying the Transit VPC (not 10.100.0.0). When PAGroupCft runs, it outputs the correct gateways for the Transit VPC AZs, but seems to keep a hard coded 10.100.0.0/27 and 10.100.0.32/27 for "transitVpcDmzAz1SubnetCidr" and "transitVpcDmzAz2SubnetCidr". Does this have any downstream impact or should these 2 values be removed from the PAGroupCft template?

I deployed the Transit VPC Template and then the Subscribing VPC template and they completed successfully. When it Launches the PaGroup Stack it fails with error: "Stack creation time exceeded the specified timeout." Is there a way to increase the timeout for the PaGroup creation?

I'm unclear about how traffic is routed into the PAs from the internet and how HA will work.

I am trying to recreate this template in a region where deploying the cft directly is unsupported. In my solution I only have 1 PA in each AZ, once primary, one secondary. I understand the usage of MED values for fail-over of internal routing between transit VPCs, but from the internet there is no determinant on which PA to hit.

I've seen other vendors use an EIP which bounces association between the ENI of the primary device, but I don't see any of that magic happening in any lambda functions....

Any help would be great!

I have a situation where I was deploying multi-account transit VPC, where the transitvpc account will also be a subscriber. When I initially deployed this, I did not specify the transit account in the list of accounts that must be defined in initializeTransitAccount.json cfn parameter SubscriberAWSAccountNumber.

So when I tried to trigger a new subscribingVpc in the transit account, I got the following error in createVpnConnection-transitVpcSubscriberAccount lambda.

[INFO]  2019-01-06T16:05:33.284Z  e49eacd3-c5f8-4a47-8dcc-376209e84b4c  Publishing to Transit-SNS Topoic arn:aws:sns:us-east-1:767xxxxxx804:transitSns-transitVpcAccout By assuming Role arn:aws:iam::767xxxxxx804:role/TransitAssumeRole-transitVpcAccout
[ERROR] 2019-01-06T16:05:33.565Z  e49eacd3-c5f8-4a47-8dcc-376209e84b4c  Error in publishToSns(), Error: An error occurred (AccessDenied) when calling the AssumeRole operation: Access denied

Adding the transit account number to the SubscriberAWSAccountNumber in the initializeTransitAccount.json cloud formation stack fixed this issue. To help others avoid this, suggest updating the deployment guide and/or updating the comments for the parameter in the embedded documentation in file: cfts/initializeTransitAccount.json. Change:

84       "Description": "Subscriber AWS Account number(s) required for Assume Role, Provide comma separated valid 12-digit AWS Account Number. Note: While doing stack Update, add account numbers to the existing account numbers. If you delete the existing account numbers, those accounts no longer subscriberd with Transit Account",

should say:

84       "Description": "Subscriber AWS Account number(s) required for Assume Role, Provide comma separated valid 12-digit AWS Account Number. Note: While doing stack Update, add account numbers to the existing account numbers. If you delete the existing account numbers, those accounts no longer subscribed with Transit Account. If the TransitVPC account is also a Subscribing account, include it also",

I'll submit a simple PR for this.

Deploying these templates and PAGroup58 launches. However using the default password from the deployment document I cannot login. Also setting a new phash in the bootstrap file did not work as well. I am new to Palo Alto. If I look at the phash in the config, should it list more than an "*"

admin@PA-VM# show mgt-config users
users {
admin {
phash *;
permissions {
role-based {
superuser yes;

The volumes for the firewalls are not flagged delete on terminate, leaving old volumes around when the solution is scaled down or deleted.

Lambda function fectchFromSubscriberQueueLambda fails when there are no messages on subscriber queue:

argument of type 'NoneType' is not iterable

This can be fixed by validating receive_message variable like this:

if receive_message:
       for message in receive_message['Messages']:
                    action=message['Body']
                    action=json.loads(action.replace('\'','\"'))
                    return action

Hello,

I spend quite a few hours on a Palo TAC case troubleshooting an issue with the BGP peers for the Transit solution flapping every few minutes. We finally found the issue yesterday and it was due to the fact that the ARP TTL was expiring for the VPC's default gateway. We realized that the mask was misconfigured on the Palo and didn't match the mask we used for the transit. Our cloud team designed everything with /23s, but a /27 still configured as the mask on the "eth1" network object used for the static IP. The IP address was correct, just not the mask.

I've been trying to disgest the code more to see if I could ID where this issue was occurring. The best I can see given the limited amount of time I have is I noticed in the Cloudwatch logs for checkStackStatusLambda.py the following.

Peering of new PA Group: {'Az2SubnetCidr': '10.100.0.32/27', 'Az2SubnetGw': '10.13.2.1', 'N2Eip': 'X.X.X.X', 'N1Eip': 'Y.Y.Y.Y', 'PaGroupName': 'maskedname', 'Az1SubnetCidr': '10.100.0.0/27', 'N2Pip': '10.13.3.143', 'N1Mgmt': '10.13.9.56', 'N1Pip': '10.13.1.145', 'Az1SubnetGw': '10.13.0.1', 'N1Id': 'i-1234', 'N2Mgmt': '10.13.11.174', 'N2Asn': '64778', 'N2Id': 'i-1234', 'N1Asn': '64777'}

Where are these 10.100.0.32/27 addresses coming from? I did not use those in any parameters when I deployed the CFN, and I noticed that the object name was the SubnetCidr and it happened to be a /27, which I wonder if that is where the solution got a /27 from.

This issue caused some major heartburn for a project I am deploying. Can you guys check the code and mask sure it will configure the correct mask on the PANs?

My apologies if I missed something. But does this solution require Panorama? How are the configurations being synchronized between the Firewalls in different AZ's?

Cann we have a variable number of subnets / AZs in the subscriber VPC? Many solutions, particularly database but really anything that has a highly redundant management plane, requires three "controllers" or master units for proper master election and to avoid split-brain situations. There are many academic and industry papers on the topic, so I won't get into details, but the ideal minimum number is three. While I understand that all AWS regions don't support three AZs, the majority does, and there should be an option for specifying the number of AZs / subnets per subscriber VPC.

I have built a Lab Transit VPC + Sub config and am planning to add Non-Lab Transit VPC + Subs config. I'd like to use the same account for both Transit VPCs. Has anyone tried this? I would prefer not to break the existing Transit-Lab by standing up another, hoping that someone has tried this before.

Cross posted from Live.

Hi team,

After setting tag to Yes, the VPNs do not come up (we have waited about 1 hour).
Any clues?

Thanks

In the initializeTransitAccount.json cloudformation template the SQS setup requests to create a FIFO queue which limits the available regions you can deploy this stack to only the following regions US East (N. Virginia), US East (Ohio), US West (Oregon), and EU (Ireland). Removing the fifoqueue = true and contentbaseddeduplication = true allowed us to continue in Sydney (AP-Southeast-2).

There is an unknown public key associated with the admin account in bootstrap.xml. Should it be removed from the bootstrap?

Current pull doesn't bootstrap the config. Getting btsErrorConfig: Media missing directory: software(4) from the instance screenshot. I have tried combining the lambda/bootstrap bucket and separating them, both times the bootstrap isn't seen. PAgroup stack shows correct bootstrap bucket, and all 4 folders are in that top level bucket. Don't have any issues pulling python scripts and CFTs from s3 buckets

Edit: More info - Using default bootstrap.xml doesn't work either, as the username/password is invalid until I SSH into the PAs and change their password. After that I can build VPNs fine. I am pretty sure I'm doing everything right, I have an PA AutoScale group in another VPC that works fine and sees it's S3 buckets.

Instance user data shows the correct s3 bucket for bootstraping.

Edit: Resolved - you can't upload the folders directly from the prerequisite folder, you need to create them manually in S3. Works fine after that.

We are trying to configure a Palo Transit VPC. We are having issues getting the routes received via one of the BGP Peer groups (VPC A) to Advertise out to another BGP Peer Group (VPC B). The Palo has a private AS while both VPC A and VPC B have the same AS. The palo will not advertise received BGP routes out to the other peer.

Hi everyone

I'm doing this procedure to create a transit vpc using a previous creating subscriber vpc, the subscriber vpc already has a IGW and VGW. When I ran the CFT to create a subscriver vpc with the option to tag an existing vpc, the firewalls instances are created but no VPN connection is created. the question is there a way to tell me what I need to modify or what I need to do in order to tag an existing subscriber vpc to work with VPN connections?

Wondering if anyone else is seeing this, am following the documentation closely. Was able to run the CFTs and link a subscriber VPC. The PAGroup template ran, spun up two nodes with two ENIs, one in an untrust subnet with elastic IP attached, another in a trusted subnet. When I log into the Palo Alto device, it has only recognized one interface, the public interface, and has associated management to it. I can browse to the web UI from the internet.

I had a situation where I incorrectly entered the PaGroupTemplateUrl when setting up the transit vpc account, which caused an error in the createNewPaGroup-transitVpcAccout function, failing with the following exception:

botocore.exceptions.ClientError: An error occurred (ValidationError) when
calling the CreateStack operation: TemplateURL must be an Amazon S3 URL.

Realizing my mistake, I then tried correcting the error by updating the stack. The updated stack applied just fine, but got the same error.

Digging into the DynamoDb table: TransitConfig-transitVpcAccout, I noticed that the parameter: PaGroupTemplateUrl was still set to the original, incorrect url for the paGroupCft.json file, even though the cloud formation stack had been successfully updated.

I learned that the causes is that the lambda TransitConfig-transitVpcAccout does not update the dynamo tables on a cloudformation update event.

I will submit a PR to update lambda/initializeTransitDynamoTables.py from:

158     elif event['RequestType'] == 'Update':
159         if accountNumbers:
160             updateAssumeRole(roleName, accountNumbers)
161             cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, "CustomResourcePhysicalID")
162         else:
163             cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, "CustomResourcePhysicalID")
164     elif event['RequestType'] == 'Delete':

to:

158     elif event['RequestType'] == 'Update':
159         if accountNumbers:
160             updateAssumeRole(roleName, accountNumbers)
161             cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, "CustomResourcePhysicalID")
162         else:
163             cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData, "CustomResourcePhysicalID")
>164         #Update DynamoDB TranstiConfig Table
>165         updateTransitConfig(transitConfig, event['ResourceProperties'])
166     elif event['RequestType'] == 'Delete':

Each PA Group (acts as a single logical unit and has two nodes in two az's for redundancy) has a limit on maximum number of VPCs (X) it can establish a VPN with.

Can someone help me with the limit as number of VPC's it can establish VPN to?

No PaGroup58 is getting launched, I am getting this invocation error for the Lambda function:

Expecting value: line 1 column 1 (char 0): JSONDecodeError
Traceback (most recent call last):
File "/var/task/cloudtrailLambda.py", line 98, in lambda_handler
parse_log(FILENAME)
File "/var/task/cloudtrailLambda.py", line 52, in parse_log
d = json.loads(f.read().decode("utf-8"))
File "/var/lang/lib/python3.6/json/init.py", line 354, in loads
return _default_decoder.decode(s)
File "/var/lang/lib/python3.6/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/var/lang/lib/python3.6/json/decoder.py", line 357, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

I have deleted both Pa nodes by mistake, is there a way to spin new ones in transit VPC without creating new T-VPC again, adding new subscriber didn't work out?

Thank you

The deployment guide documentation indicates that to change the palo alto password in the bootrap.xml, the users have to apply the
palo bootstrap.xml config and change then password and export the config again.
There is an easier way using mkpasswd echo newpassword | mkpasswd -m MD5 -S acfwlwlo -s

And the bootsrap.xml file can be updated programmatically with xq (installed with
the 'yq' program and works just like 'jq').

Put it all together now...

# Define the new password
NEW_PASSWORD="CssCloud123!"

# Define the Boostrap.xml location
BOOSTRAP=./prerequisites/bootstrap/config/bootrap.xml

# This is the salt used by the palo password in the example doc
SALT=acfwlwlo

# Create the new md5 password hash
NEW_HASH=`echo $NEW_PASSWORD | mkpasswd -m MD5 -S $SALT -s`

# Create a backup of the file
cp $BOOSTRAP $BOOSTRAP.bak

# Update the boostrap.xml
xq -x --arg PHASH $NEW_HASH '.config["mgt-config"].users.entry.phash = $NEW_HASH' $BOOSTRAP.bak > $BOOSTRAP

Might be a good tip to add to the documentation.

Unable to deploy initializeTransitAccount.json Cloudformation template as it is too large for the limit of 460800 bytes.
Does anyone have a smaller or nested version?
Thanks

Am building a second transitVPC in the same account. Watching the progress through CloudWatch Logs and the State machine step function. It fails here, when trying to create the stack. There is supposed to be a Check state lambda that executes immediately after but it does not.

Why is PaGroup58 the first one to be built? Can it be just a random number or full concatonated date and time (ie 20180822163045)

An error occurred (AlreadyExistsException) when calling the CreateStack operation: Stack [PaGroup58] already exists: AlreadyExistsException
Traceback (most recent call last):
File "/var/task/createNewPaGroupLambda.py", line 48, in lambda_handler
response = pan_vpn_generic.createNewPaGroup(region, result['PaGroupName'],config['PaGroupTemplateUrl'],result['PaGroupName'],config['SshKeyName'],config['TransitVpcMgmtAz1SubnetId'],config['TransitVpcMgmtAz2SubnetId'],config['TransitVpcDmzAz1SubnetId'],config['TransitVpcDmzAz2SubnetId'],config['TransitVpcTrustedSecurityGroupId'],config['TransitVpcUntrustedSecurityGroupId'],config['PaGroupInstanceProfileName'],config['PaBootstrapBucketName'], str(result['N1Asn']), str(result['N2Asn']), config['TransitVpcDmzAz1SubnetGateway'], config['TransitVpcDmzAz2SubnetGateway'])
File "/var/task/pan_vpn_generic.py", line 552, in createNewPaGroup
OnFailure = 'ROLLBACK'
File "/var/runtime/botocore/client.py", line 314, in _api_call
return self._make_api_call(operation_name, kwargs)
File "/var/runtime/botocore/client.py", line 612, in _make_api_call
raise error_class(parsed_response, operation_name)
botocore.errorfactory.AlreadyExistsException: An error occurred (AlreadyExistsException) when calling the CreateStack operation: Stack [PaGroup58] already exists

If you deploy the transit-vpc solution for the first time, without having ever deployed the Palo Alto virtual appliance in the TransitAccount, the cfts/paGroupCft.json will never create the EC2 instances and will time out and roll back, with no indication of why.

I finally figured out that it was because we had not ever deployed a Palo Image from the AWS Marketplace before in that Account and as such, had not accepted the Palo EULA. To correct this, I manually deployed a Palo instance in EC2, accepted the EULA then terminated that manual instance. From the on, paGroupCft.json worked.

I didn't see this in the documentation anywhere. Suggest that a note is added to the top of the deployment guide to provide assistance to others. Also suggest the deployment guide be in markdown (not pdf) so that the community might issue pull requests to improve the documentation.

Thanks!

Hi!

Testing out this setup but got stuck.

1. The transit VPC have been created ok using the initializeTransitAccount.json. (I have tried to change the PaloAltoGroupCapacity to from default to 6 just to see if that changes the behaviour)
2. I'm running the initializeSubscriberAccount.json template to create a subscriber VPC
   2.1. VPC is created
   2.2. The PaGroup cft starts
   2.3. The virtual Palo instances are started and I can access them via gui/ssh
   2.4. Next I would expect the VPNs to be configured but nothing happens and after some time a new PaGroup cft starts kicking up yet another pair of virtual Palo instances, this goes on untill my pool for EIP are emptied and the PaGroup cft starts failing. By this time I have a whole bunch of Palos running....

Not sure exactly what goes wrong but after some digging I found the following in CloudWatchLog Groups/aws/lambda/fetchVpnServerDetails-palo-transit-vpc-cf:

START RequestId: c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c Version: $LATEST
[INFO] 2018-09-12T09:37:24.805Z c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c Got Event: {'Action': 'FetchVpnServerDetails', 'VpcId': 'vpc-0cedc636159bd1ff2', 'VpcCidr': '10.166.128.0/22', 'Region': 'eu-west-1', 'Rebalance': 'False', 'SubscriberSnsArn': 'arn:aws:sns:eu-west-1:xxxxxxxxx:subscriberSnsTopic-palo-subsciber-vpc3-cf', 'SubscriberAssumeRoleArn': 'arn:aws:iam::xxxxxxxxx:role/SubscriberAssumeRole-palo-subsciber-vpc3-cf', 'ReceivedFrom': 'fetchVpnServerDetails'}
[INFO] 2018-09-12T09:37:24.831Z c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c Starting new HTTPS connection (1): dynamodb.eu-west-1.amazonaws.com
[INFO] 2018-09-12T09:37:25.89Z c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c Starting new HTTPS connection (1): dynamodb.eu-west-1.amazonaws.com
[INFO] 2018-09-12T09:37:25.243Z c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c Scan results of VpcTable: []
[INFO] 2018-09-12T09:37:25.290Z c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c PaGroup Info scan result with Fileter InUse=YES and VpcCount < 6 is: [{'N2Asn': '64828', 'VpcCount': Decimal('0'), 'PaGroupName': 'PaGroup58', 'InUse': 'YES', 'N1Asn': '64827'}, {'N2Asn': '64880', 'VpcCount': Decimal('0'), 'PaGroupName': 'PaGroup84', 'InUse': 'YES', 'N1Asn': '64879'}, {'N2Asn': '64770', 'VpcCount': Decimal('0'), 'PaGroupName': 'PaGroup29', 'N2Eip': '52.49.5.xxx', 'N1Mgmt': '10.166.0.83', 'StackRegion': 'eu-west-1', 'N2Mgmt': '10.166.0.110', 'N1Pip': '10.166.0.5', 'N2Pip': '10.166.0.55', 'InUse': 'YES', 'N1Asn': '64769', 'N1Eip': '34.250.189.xxx'}, {'N2Asn': '64834', 'VpcCount': Decimal('0'), 'PaGroupName': 'PaGroup61', 'InUse': 'YES', 'N1Asn': '64833'}, {'N2Asn': '64748', 'VpcCount': Decimal('0'), 'PaGroupName': 'PaGroup18', 'N2Eip': '34.254.31.xxx', 'N1Mgmt': '10.166.0.80', 'StackRegion': 'eu-west-1', 'N2Mgmt': '10.166.0.104', 'N1Pip': '10.166.0.15', 'N2Pip': '10.166.0.46', 'InUse': 'YES', 'N1Asn': '64747', 'N1Eip': '52.48.39.xxx'}, {'N2Asn': '64730', 'VpcCount': Decimal('0'), 'PaGroupName': 'PaGroup9', 'N2Eip': '34.246.247.xxx', 'N1Mgmt': '10.166.0.76', 'StackRegion': 'eu-west-1', 'N2Mgmt': '10.166.0.107', 'N1Pip': '10.166.0.25', 'N2Pip': '10.166.0.43', 'InUse': 'YES', 'N1Asn': '64729', 'N1Eip': '54.194.178.xxx'}, {'N2Asn': '64812', 'VpcCount': Decimal('0'), 'PaGroupName': 'PaGroup50', 'N2Eip': '52.215.174.xxx', 'N1Mgmt': '10.166.0.85', 'StackRegion': 'eu-west-1', 'N2Mgmt': '10.166.0.105', 'N1Pip': '10.166.0.29', 'N2Pip': '10.166.0.37', 'InUse': 'YES', 'N1Asn': '64811', 'N1Eip': '34.248.49.xxx'}, {'N2Asn': '64772', 'VpcCount': Decimal('0'), 'PaGroupName': 'PaGroup30', 'InUse': 'YES', 'N1Asn': '64771'}]
[INFO] 2018-09-12T09:37:25.308Z c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c PA-Groups are exausted, hence pushing the message back to Queue and passing control to CreateNewPaGroup function
[INFO] 2018-09-12T09:37:25.428Z c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c Starting new HTTPS connection (1): eu-west-1.queue.amazonaws.com
END RequestId: c2fe9d28-7cf5-47f0-8e8d-b2445a25a33c

Why do I get "PA-Groups are exausted" when I have no VPNs configured yet, I would expect this to happen when I reach the limit I have configured (6)?

Thankful for any help!

Br,
/J

Suggestion to add documentation or at least a note that the PANs needs to be setup for outbound NAT to eth1 elastic IP interface in order to provide internet connectivity for the subscriber VPC. Could be added on to the doc describing how to redistribute default from transit VPC PANs.

What is the purpose of the NAT Instances in the subscriber VPC? As far as I can tell, there is no purpose. I can see if you wanted to use it as a bastion host to get to hosts inn the subscriber VPC if things were not working, but this is a security risk also. Can we have an option as to whether to spin up a NAT instance, subnets, and IGW?

I see that there are 2 different templates available one for VPC and other for auotscaling vmseries firewall. Is possible to combine both to create get autoscaling solution along with VPN tunnels. Reason for checking is currently auroscaling firewall doesnt include ipsec vpn tunnel just only firewall.

The Transit and Subscriber templates completed without issue. However the PaGroup58 stack never gets launched. On closer inspecting the Lambda function was triggered but failed.

The PA Group Lambda function fails with the following error:

An error occurred (ValidationError) when calling the CreateStack operation: Parameters: [PaGroupTemplateUrl, UserName, DeLicenseApiKey, SubscriberAWSAccountNumber, LambdaFunctionsBucketName, VpnConfigBucketName, Password] must have values: ClientError

Any ideas?

I would like to propose to change all lambda code to a different repository and have its own release cycle and ask customers to use a released tag. Otherwise whomever updates any lambda code has to manually zip it and update it.

Hello,

I have an existing transit VPC with existing VPC peers that I would like to deploy this solution to. I've worked though the deployment guide and nothing appears to happen after deploying the initializeSubscriberAccount template in the transit account, and then InitializeSubscriberAccount in the peered vpc spoke account (LaunchSubscriberVPC parameter = No), and then tagging the spoke vpc with "subscribingVpc" : "yes". Can you please offer some thoughts on what the problem might be, or some troubleshooting tips?

Thanks.
John

Hello,

I deployed all the stacks and everything seems OK. The tunnels are up.
I'm trying to do some routing tests (point 11 in the deployment guide). I have set up an EC2 instance in the Subscriber VPC (AppAz1 subnet). ICMP is allowed on all security groups. And I have manually put the VGW as default route for the routing table "Subscribing-priv-rt" (the one associated with the AppAz1 subnet). In this situation I'm still not able to ping the private IP address Eth1 of the Palo Alto. Is there something I am missing?

Thank you in advance.

To fix the bugs, apply the following fixes:

• Remove "AWS": "arn:aws:iam::210278571640:root", from line 102
• Remove comma from end of line 257
• Remove comma from end of line 280

Hi Narayan,

We got Error Code "Error from subscriberVpn Configuration, Error: local variable 'vpnId1' referenced before assignment" and "Publishing message to Transit SNS with subject SubscriberVpnConfigurationFailed, because of Error: local variable 'vpnId1' referenced before assignment" for this lambda function.

Please assist us. We are waiting for your response.

#Jayadeep Damarla

Hey all,

Ive got a PoC environment provisioned via the cfts (hub and both spokes deployed via PA cfts) and all the stacks have created successfully. However, when the transitStateMachine step function invokes the checkStackStatus function it get stuck in a loop.

It looks like the following declaration is failing causing the "Error while retrieving API Key" entry in the logs:

panStatus=pan_vpn_generic.checkPaGroupReady(config['UserName'],config['Password'],stackStatus)

I've validated that I can log into the appliances in the PA group over SSH using the credentials defined in the transit VPC cft. So I assume its some sort of issue that Lambda is having when trying to communicate with the EC2 instances. Being that everything in the transit and subscriber VPCs created successfully, I am unsure of where to start.

Any guidance would be appreciated. Thank you!

Hi. I tried to deploy initializeTransitAccount.json at Frankfurt region because it's missing FIFO SQS feature.
But since our company is using PA routers in the Datacenter we want to have them at the cloud as well.
And I've made some nice patch to the template that create SQS queues in other region and deployment succeded. I would like to contribute to this project and can make PR if someones needs this.

After a day or so, the firewall stop responding to their public ip address. I rebooted one of the instances in AWS and was still unable to connect via web or ssh. Also, once i rebooted the one instance, the VPN tunnel on the AWS side wouldn't come up. Help?

The App subnets (pdmz) in the transit VPC do not appear to be connected. There is no route table for these subnets, and no interface/zone on the firewalls that the non-existent route table points to. I understand that there are no firewalls launched until the first subscriber VPC is added. However, the whole solution is kind of useless without at least one subscriber account, so there should be a route-table created for the pdmz subnets and when the first firewalls are provisioned the route table should be modified to point the default route to the "inside" or "trusted" interface/zone on the firewall (which also does not exist). I also realize that the recommendation is to use a separate subscriber VPC for core services, and not put them in the Transit VPC. But then why create these subnets?