- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
04-12-2021 11:12 AM
We have deployed vm-series 300 in AWS recently and put our production site behind it, but we are seeing a performance degradation, the website is taking around 2-3 mins to load for the first time which normally it didnt take, we have not put any url filtering profiles yet but yes we do have some security and nat profiles in place(which normal I believe), I just wanted to understand what could be the reason for the slowness and what all things can be checked in PA to troubleshoot.
PS: I am attaching a screenshot of developers tool console to show time it takes for the page to load first time
04-12-2021 11:25 AM
How are you directing traffic to the firewalls? If you are using an ALB/NLB, ensure that your routing allows the firewalls to communicate with all of the LB Subnets via the same interface that is specified in the Target Group. Similar question on the backend. If the application is deployed across multiple subnets, ensure the firewall can route to all of the backend subnets via the SNAT interface.
04-12-2021 11:33 AM
Yes, we are using NLB, which is deployed in 2 subnets across 2 az's, the backed firewalls are also in the same AZ's. The backend to the firewall is an Haproxy which are also spread across the same az's.
What else can I check?
04-12-2021 11:48 AM
There is a very good chance that your external interface cannot route to the NLB subnet in the other zone or that your Trust side interface cannot route to the other zone. If you can post your subnet lists and your firewall VR "More Runtime Stats", we may be able to see the issue.
Also watch that you do not have "Automatically create default route pointing to default gateway provided by server" enabled on both of your interfaces.
04-12-2021 07:45 PM
I am sure of the second point you have mentioned, no we did not do that.
For the first, I'll check and get back to u
04-12-2021 08:04 PM
see below on the picture. You have to make sure that on the interface on the firewall are you not select "Automatically create default route....."
04-12-2021 08:23 PM
Yes, we have not selected this for the trust interface
04-13-2021 05:51 AM
Please see me earlier note about posting your resultant route table from the firewall and your subnet layout.
04-13-2021 06:12 AM
10.163.6. and 10.163.5 are untrust interfaces(subnets) and 10.163.11 and 10.163.15 are trust interfaces
04-13-2021 09:12 AM
What subnets are your LB and back in? The route that I question is the /22 on only one of the firewalls. If you have backend traffic that is not in the same subnet as an interface, you could be routing it out Eth1/1 but snatting it to Eth1/2. That will cause a timeout.
On the flip side, you have a 10/8 route via eth1/2, this is going to prevent your LB health checks from return to the cross zone subnet via eth1/1.
You should have 0/0 via eth1/1 and static route for the NLB subnets also via eth1/1. You can then use the 10.8 route to get to all other subnets via eth1/2.
04-13-2021 10:18 AM
i need some time to verify this, need to look into it tomorrow morning and will get back to you
04-14-2021 10:00 PM
We have found out that it is the decryption profile which is causing the slowness, I have opened a ticket with PA support
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 LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!