I have a support call scheduled for tomorrow but if anyone has any ideas about this that would be greatly appreciated.
I deployed the classic ELB template example successfully. My customer then took the firewall.template and integrated it into their stack making it a nested stack feeding it all the parameters required.
The firewalls come up in all 3 AZs, they have EIPs attached to each firewall. Yet the firewalls never come out of 'out of service' status. We can't connect to the EIP even though they're associated to the firewalls' management interfaces.
According to the docs: if bootstrapping fails, the VM-Series firewall for load balancing traffic will be out-of-service.
How do I check the bootstrapping process? Cloudwatch logs for the lambdas?
Solved! Go to Solution.
in AWS you should be able to look at the console log snap shots and see the process. But if it is has been some time since it scaled or powered up then the console log output may not show anything.
Also the ELB will say out of service if it can't reach anything on the backend to do a health check. For testing you can try to check the health checks to verify via TCP just to see if it work. Of course the load balancer would have to be a classic ELB
Thanks. Both public and internal load balancers are classic. Where exactly in the GUI are you referring to in the console when you say "console log snap shots" ?
We have been creating/deleting stacks while testing so no problem checking right after firewalls come up. The difference between the customer's template and the classic example seems minor. Hopefully the TAC engineers will know where to look.
Thanks. As it turns out everything was properly configured yet the firewalls would not bootstrap properly. After TAC support attached an EIP to the public interface and got the log in page it appears that the mgt switch command in the init-cfg.txt didn't work. After deleting the init-cfg.txt (which had the proper text in it) with a fresh copy directly from the github page the firewalls came up as expected. So a 37 byte file somehow got corrupted.
i'm happy to hear everything is working and thanks for updating us also. Everyone once in a blue moon that will happen. The trick is to be sure that when you download the files from the GitHub resource you either Clone the resource or you click the RAW button and right click save as to save the file. If you right-click save as before clicking the RAW button then the file will download in a format that will not work. That may be what happened with the first download but either way I'm happy it works for you now. Take care.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!