aws-transit-vpc icon indicating copy to clipboard operation
aws-transit-vpc copied to clipboard

Stacks deployed, but nothing seems to happen. Please advise.

Open jcleve opened this issue 6 years ago • 7 comments

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

jcleve avatar Apr 04 '18 21:04 jcleve

You'll have to deploy the initialize subscriber account by template in the spoke account. And then tag the spoke vpc.

-- Thanks, /narayan


From: jcleve [email protected] Sent: Wednesday, April 4, 2018 2:44:52 PM To: PaloAltoNetworks/aws-transit-vpc Cc: Subscribed Subject: [PaloAltoNetworks/aws-transit-vpc] Stacks deployed, but nothing seems to happen. Please advise. (#11)

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

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_PaloAltoNetworks_aws-2Dtransit-2Dvpc_issues_11&d=DwMCaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yaPPNRHFJOEqZ9-bfG64oiDWvBigyIWTnqkw0GQeLyU&m=3a4PovfqJuhS2VINltQPCdQNiGU7P0aeVCrH4es1Tk0&s=d_14CGcObJbsmgHCADaTG5gNGDXofUFRXRF_h4cBDDQ&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ARFcabd9ApjXHZoB8O-5FkZw84YnwIGKFmks5tlT7UgaJpZM4THjDA&d=DwMCaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yaPPNRHFJOEqZ9-bfG64oiDWvBigyIWTnqkw0GQeLyU&m=3a4PovfqJuhS2VINltQPCdQNiGU7P0aeVCrH4es1Tk0&s=-79TUne_v9pF-T4cytgvAZb9pWt-KNRJS8T2kDLr3IM&e=.

narayan-iyengar avatar Apr 04 '18 23:04 narayan-iyengar

Hi narayan,

I did deploy the initializeSubscriberAccount template in the spoke account and then tag it per the deployment guide. Nothing happens. Please advise.

jcleve avatar Apr 04 '18 23:04 jcleve

ok, if I let the stacks create the transit vpc and subscriber vpc (as opposed to trying to use my existing) the PAgroup stack launches, but no VPNs are ever established. Any thoughts?

jcleve avatar Apr 13 '18 19:04 jcleve

sorry for the delayed response.

Tagging the VPC should have worked. After you take the VPC, do you see firewalls being spun up in the transit vpc (paGroup gets launched)? If so and the tunnels are not up, chances are your firewall was not properly bootstrapped. If the paGroup is not launched, make sure the account numbers are correct when launching the Initializer CFTs.

If VPNs are not established, it is possible that the bootstrapping of the firewall was not successful. Can you log into the firewall with the user and pass mentioned in the doc? BTW that is the user and pass you need to enter when launching the transit cft (unless you update the bootstrap.xml with your own user and pass)

Bootstrapping could fail if you enter the incorrect user/pass or your files are corrupted. Or the S3 bucket layout is incorrect (make sure you remove and dummy files in the buckets)

narayan-iyengar avatar Apr 13 '18 19:04 narayan-iyengar

I am able to log into each firewall's web interface, so presumably, bootstrapping was successful, but still no VPN tunnels have been created. What dummy files need to be removed from which bucket(s)?

jcleve avatar Apr 17 '18 13:04 jcleve

If bootstrapping is successful that means you can login in using the username and pass listed in the guide.

Then no need to remove any dummy files.

You will need to dig into the cloud watch logs to see what is causing any errors. Does your existing vpc have a vgw?

-- Thanks, /narayan


From: jcleve [email protected] Sent: Tuesday, April 17, 2018 6:50:06 AM To: PaloAltoNetworks/aws-transit-vpc Cc: Narayan Iyengar; Comment Subject: Re: [PaloAltoNetworks/aws-transit-vpc] Stacks deployed, but nothing seems to happen. Please advise. (#11)

I am able to log into each firewall's web interface, so presumably, bootstrapping was successful, but still no VPN tunnels have been created. What dummy files need to be removed from which bucket(s)?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_PaloAltoNetworks_aws-2Dtransit-2Dvpc_issues_11-23issuecomment-2D381999440&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yaPPNRHFJOEqZ9-bfG64oiDWvBigyIWTnqkw0GQeLyU&m=bfB0_cGhwBkic_WKUQpJ8_3tG189UtoLrliSrGNAPfg&s=uzw5b2ZMKCv8WoS1P8I3YsWPs8zEcCOS_aWavVdS_-g&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ARFcaV8IqGecazxzQzLEwP-2DxTwx9Y5d8ks5tpfMOgaJpZM4THjDA&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=yaPPNRHFJOEqZ9-bfG64oiDWvBigyIWTnqkw0GQeLyU&m=bfB0_cGhwBkic_WKUQpJ8_3tG189UtoLrliSrGNAPfg&s=yvh4NdK3XYXHLZ-5I8P1xhDZc0z41rT0S6FMVqn0DTQ&e=.

narayan-iyengar avatar Apr 17 '18 13:04 narayan-iyengar

There is a general problem with passing the CIDR for the DMZ through to the code that is used to configure the firewall. See #7 . Generally what this means is that the subnet mask for the outside interface is always configured as /27 regardless of what is specified as a parameter for the intializeTransitAccount.json stack. If you use a subnet that is larger (less bits), the firewall may get an IP that can't reach its own default gateway, resulting in no VPN connectivity. Check your eth1 object in the firewall to make sure it has the right mask. I've had it establish VPNs to one firewall but not the other precisely because of this. I'm working on a fix for this.

If not that, do you actually have VPN configuration show up in AWS in the subscriber account?

freimer avatar May 04 '18 17:05 freimer