Ivanti Pulse secure on AWS-Pool subnet routing not working...

Based on the information provided, it seems you're experiencing routing issues with your Ivanti Pulse Secure VPN setup in AWS. Here are some suggestions to help troubleshoot and potentially resolve the issue:

1. Verify route table configurations: Ensure that the route tables associated with your VPC subnets, particularly the subnet where the Ivanti VPN gateway is deployed, have the correct routes for the pool subnet (192.168.20.0/24) pointing to the Ivanti internal interface. This should be done not only in the "Gateway routing table" but also in the main route table of the VPC.

2. Check security group and network ACL settings: Review the security group attached to your Ivanti VPN instance and the network ACLs associated with the subnets. Make sure they allow traffic from the pool subnet (192.168.20.0/24) to flow to and from the on-premises destinations.

3. Verify on-premises routing: Confirm that your on-premises network devices (routers, firewalls) have the correct routes to send traffic back to the pool subnet (192.168.20.0/24) via the AWS VPN connection or Direct Connect, whichever you're using for connectivity.

4. Check NAT configuration: Ensure that the Ivanti VPN gateway is correctly configured to perform NAT (Network Address Translation) for the pool subnet. The VPN clients should appear to come from the pool subnet IP addresses when communicating with on-premises resources.

5. Analyze VPN logs: Review the Ivanti Pulse Secure VPN logs for any errors or warnings related to routing or connectivity issues. This may provide insights into what's happening when clients try to access on-premises resources.

6. Use packet capture: If possible, perform packet captures on the Ivanti VPN gateway's internal interface to see if traffic from the pool subnet is being correctly forwarded.

7. Test with a static IP: As a troubleshooting step, try assigning a static IP from the pool subnet to a VPN client and see if it can reach on-premises destinations. This can help isolate whether the issue is with the pool subnet routing or something else.

8. VPC Flow Logs: While you mentioned that VPC Flow Logs weren't of much help, consider creating more granular flow log configurations focusing specifically on the traffic between the pool subnet and your on-premises network. This might provide more detailed insights.

9. AWS Support: If you're still unable to resolve the issue, consider reaching out to AWS Support. They can provide more in-depth assistance and potentially identify any AWS-specific networking issues that might be affecting your setup.

Remember to make changes cautiously and document each step of your troubleshooting process. This will help in case you need to revert any changes and will be valuable if you need to escalate the issue to Ivanti or AWS support.

Sources
Troubleshoot VPN routing issues | AWS re:Post
Troubleshooting AWS Client VPN: Access to a peered VPC, Amazon S3, or the internet is intermittent - AWS Client VPN

Introducing a transit gateway resolved this issue finally which is acting as Layer-3 IP router now. However, AWS documentation should clearly say the limitations around VGW like this which acts as just Layer-2 switch inside VPC as well as no visibility/flexibility when dealing with direct connect. You can't even define a default static route with destination as "direct connection", this is also needs to learn through BGP.

Such a very simple requirement was a daunting task to execute in AWS and I was literally thinking about stone age though we say next-gen cloud.