Skip to content
This repository has been archived by the owner on Jul 7, 2021. It is now read-only.

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

Open
jcleve opened this issue Apr 4, 2018 · 7 comments
Open

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

jcleve opened this issue Apr 4, 2018 · 7 comments

Comments

@jcleve
Copy link

jcleve commented Apr 4, 2018

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
@narayan-iyengar
Copy link
Contributor

narayan-iyengar commented Apr 4, 2018 via email

@jcleve
Copy link
Author

jcleve commented Apr 4, 2018

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
Copy link
Author

jcleve commented Apr 13, 2018

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?

@narayan-iyengar
Copy link
Contributor

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)

@jcleve
Copy link
Author

jcleve commented Apr 17, 2018

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)?

@narayan-iyengar
Copy link
Contributor

narayan-iyengar commented Apr 17, 2018 via email

@freimer
Copy link

freimer commented May 4, 2018

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?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jcleve @freimer @narayan-iyengar