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

0

Hi,

Does anybody hosted Ivanti Pulse secure VPN GWs in AWS?

Here are the details...

  1. VPC subnet - 192.168.16.0/22
  2. Ivanti - external subnet - 192.168.16.1/28; internal subnet - 192.168.16.33/28 and Pool subnet (for remote access users) - 192.168.20.0/24

It's working fine to reach any destinations to on-premise destinations through internal interface IP address of Ivanti & Pool subnet as such not assigned/configured for any specific interface. Pool subnet is used by Ivanti to assign for remote users translating to one of this subnet IP addresses before sending towards on-premise. We also configured a specific route in "Gateway routing table" for 192.168.20.0/24 pointing to Ivanti internal interface.

Problem: Remote users are able to login into Ivanti but not able to reach to on-premise destinations. The same destinations are reachable properly when we use Ivanti internal interface IP and also the whole VPC subnet is also available in On-premise gateways.

  1. Any pointers to resolve this issue as it's getting blocked somewhere after entering into AWS?
  2. We tried with flow logs but not of big use. Any other troubleshooting techniques to quickly identify what's happening behind the scenes?

Thanks in advance... Regards... Ashok.

2 Answers
0

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

profile picture
answered 15 days ago
0

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.

answered 16 hours ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions