Problem create VPN with TAG subscribingVpc = Yes about aws-transit-vpc HOT 39 OPEN

Hi,

I have full access to everything in the permissions, but could it still be a permissions problem? doesn't seem to write in dynamodb for create vpn.

regards,

from aws-transit-vpc.

from aws-transit-vpc.

Yeah. the script creates without problems a second machine but never creates a vpn between vpc's.
regards

from aws-transit-vpc.

Any news about this? I'm experiencing the same problem. The InitializesubscribeAccount template has been run but when changing the tag, no VPN is created.

from aws-transit-vpc.

We are having the same problem. Our existing VPC does not have an existing VGW or IGW.

from aws-transit-vpc.

Have you run the InitializeTransitaAccount template in the hub?

If you have and still tunnels don't come up, try to log into one of the firewalls using the user/pass described in the doc.
If that fails, then chances are bootstrapping has failed.

Make sure your bootstrap bucket is properly organized and that the bucket is in the same region as the hub transit (where you deployed the initialize template)

from aws-transit-vpc.

Hello,

Yes, the InitializeTransitAccount has been launched successfully.
In fact, I can "attach" a subscribing VPC by the Option 1 described in the document.
However I have another VPC which already exists and I want to attach it via Option 3. So, I just added a tag (key: subscribingVpc and Value: Yes). It seems the "CloudTrailLambda" function is triggered (that's what I see in CloudWatch), but in the end, the VGW is not attached to the VPC. The VPC does not have any IGW nor VGW previously configured. It just has one subnet, and there is no instance in it. It is basically a brand new VPC with only one subnet in it. Are there specific conditions to be matched by the VPC that has to be attached with Option 3?

Thank you in advance.

from aws-transit-vpc.

from aws-transit-vpc.

Hello,

Yes indeed, I can log into them without problem! The VPN tunnels are up to the VGW of the VPC deployed via Option 1. However, deployment via Option 3 still does not work.

from aws-transit-vpc.

Same problem here.

from aws-transit-vpc.

Hello, I just tried again and this time, it has worked!! I think I wrote the key "SubscribingVpc" instead of "subscribingVpc". Maybe the case is important for the tag?

from aws-transit-vpc.

from aws-transit-vpc.

I always had subscribingVpc and it never worked. Did you put in "yes" or "YES" as the value?

from aws-transit-vpc.

from aws-transit-vpc.

Doesn't work for me when i put an existing VPC without an IGW and VGW and tag it with subscribingVPC = YES

from aws-transit-vpc.

from aws-transit-vpc.

from aws-transit-vpc.

Hello,

Just a note from my experience: you need to wait quite a long time for the PAGroup58 to be fired up. At least 10 minutes + time to initialize the FWs + time to bring up the VPNs. So, in total 15 - 20 minutes. A small hint: check CloudWatch if you see the Lambda function be triggered.

I tried to tag another VPC as subscribing VPC which has already an IGW attached to it (no VGW but well one IGW) and it works! The VPN are coming up. Is this supported? I read in the document that it was normally not supported.

I also tried something else: I want that a specific route is injected via the VGW, not the default route as mentionned in the documentation. If you change the redistribution profile accordingly in the FW it is working. So finally, I can have a Subscribing Vpc having a default route pointing to an IGW (default route to internet) and a specific route (to another Subscribing VPC for example) pointing to the VGW going to the firewall. Is this also something that is normally supported? (no negative side effect?)

from aws-transit-vpc.

When you tagged an existing VPC, what is from another account?

from aws-transit-vpc.

from aws-transit-vpc.

When I try to tag an existing VPC from another account, it does not associate with the transit VPC. The existing vpc does not have a VGW or IGW. I am using the initializeSubscriberAccount.json to connect to spoke VPC to the transit VPC.

from aws-transit-vpc.

from aws-transit-vpc.

Yes, I’m putting the transit account number within the subscriber template. Also, I have the S3 bucket within the subscriber account. Is that correct?

from aws-transit-vpc.

from aws-transit-vpc.

Hi Vinch157. Using both an IGW and a VGW in a subscribing (spoke) VPC will work from a routing perspective. And this is published as community supported so your changes won't change the support.

But you are allowing traffic out to the internet without any inspection. This means the firewalls can't look for things like data exfiltration or connections to known malicious URLs etc. So technically this should work but we wouldn't consider this as secure.

Best practices would be to default route to the VGW and then route through the transit VM-Series firewalls to the IGW in the transit VPC. This gets you secured Internet access without hair-pinning back to an on-prem firewall.

from aws-transit-vpc.

i see the following error within the steps function when i try to tag a vpc

"error": "States.Runtime",
"cause": "An error occurred while executing the state 'ChoiceState' (entered at the event id #19). Unable to apply Path transformation to null input."

from aws-transit-vpc.

Actually, this seems to be the error that is causing the problem:

Error in publishToSns(), Error: An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::XXXXXXXX:assumed-role/SubscriberLambdaExecutionRole-Test-Spoke-VPC/createVpnConnection-Test-Spoke-VPC is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::XXXXXXXXX:role/TransitAssumeRole-Transit-VPC

from aws-transit-vpc.

from aws-transit-vpc.

thanks. i don't see the picture you attach.

from aws-transit-vpc.

from aws-transit-vpc.

Got it to work. Thanks for all the help.

from aws-transit-vpc.

from aws-transit-vpc.

Will do. But i noticed the vpn tunnels from the subscriber account are not coming up.

from aws-transit-vpc.

from aws-transit-vpc.

Hello @originalwarby,

Yes, you are completely right.
But in my setup I'm in fact trying to merge the "aws-transit-vpc" and the "aws-elb-autoscaling".
In this setup the Subscriber VPC is a spoke that is linked to two hubs:

• one southbound hub is the transit VPC (to be able to connect to other Subscriber VPCs or to the on-premises server (a VPN connection is then made between the firewalls of the Transit VPC and on premises firewall)).

• one northbound hub which is an autoscaling group of Palo Altos. This northbound hub will be interesting if the server in the Subscriber VPC is a web server (it will be able to use the autoscaling features to meet the load).

This is why, from a Subscriber VPC point of view, I have only one specific route pointing to on-premises IP range. I need to keep a default route pointing to the IGW for the autoscale setup to work correctly.

I hope this is clear?

from aws-transit-vpc.

Vinch157,

The auto scaling solution requires the VM-Series firewalls to SNAT (AWS doesn't have a symmetric return option) so you won't need a default route to the IGW for the auto scaling to work.

The traffic inbound from the internet will appear to the server to be coming from the firewall on the local network. Any traffic initiated by the server out to the internet, will take the default route to the VGW. Therefore, no default route to the IGW is required.

HTH

from aws-transit-vpc.

Hello @originalwarby,

That's the explanation I was looking for! Thanks a lot! But it seems the SNAT is not deployed by default in the CloudFormation stack. Because I made a quick test: deploy the firewall-v2.0.template and then the pan_aws_nlb_vpc-2.0.template. And I went into the routing table of the web server (application template), and I just erased the default gateway pointing to the IGW. When I do that and when I type the public URL of the public loadbalancer, I don't see the web page of the web server anymore.
I will check further in the Palo Alto config to enable SNAT.

Thanks again for your time to answer my question.

from aws-transit-vpc.

I get the following error, when i try to tag and existing VPC within the VPNFailed step function.

{
"Action": "VpnFailed",
"Reason": "VPC-CIDR Conflicts"
}

This CIDR was associated with an old VPC, but i deleted that VPC before re-creating it.

from aws-transit-vpc.

The whole system appears to be keyed off of CreateTags and DeleteTags API calls, specifically for VPCs. If you just delete a VPC it does not DeleteTags, so the automation never kicks off and the old CIDR is left in the SubscriberLocalDb DynamoDB table. Did you delete the subscribingVpc tag on the old VPC and let it clean up, or just delete the VPC? You may need to clean up manually.

from aws-transit-vpc.