Ok. Thanks for the info. It seems that either the VPN server is dropping the packets or the reply packets are not reaching back its way to the client (Reverse route issue).
NOTE: If you have configured the VPN tunneling ACLs to allow TCP and UDP based traffic only, ICMP traffic will fail, so allow ICMP as well.
For testing make it as *:* or enter it like
If you are confident that the ACLs are allowing the traffic and the full tunnel user is getting that role. Please take a tcpdump on the VPN server to check if the packets sent by the client are leaving the server or not.
Follow the below steps:
Navigate to Maintenance >> tools >> tcpdump >> enter filter as "host<space><IP address which got from the VPN server>" (without quotes) eg. host 192.168.10.5 >> turn off promis. mode >> start sniffing >> do the traceroute to 188.8.131.52 from your machine >> let it fail for 3 hops >> stop sniffing >> choose "raw" >> Get to save the dmp file >> open the dmp file using wireshark and check if you can see the ICMP packets.
Sorry for the tardy response.
I have just done your test. What I noticed is the following:
No worries..@tony.f Check your PM inbox.
Hmm. Ok. PCS is able to connect to the internet without any issues, however the client is not able to.
What is the VPN tunnelling IP subnet? Is it in the same subnet as the internal port IP address of the VPN server?
For example, if the VPN tunneling IP address leased out the client is 192.168.1.10 and the internal port IP of the VPN server was configured as 192.168.1.100/255.255.255.0, then they are in the same subnet.
If they are in the different subnet, can try assigning an IP address to the client from the same subnet as the internal port IP address of the VPN server?
VPN clients draw their IP from this pool 192.168.1.0/24.
The internal interface of PCS is in a different subnet. 10.100.100.1/24.
As you mentioned, I tried giving my machine a 10.100.100.x IP. Nothing works after this config. I think network overlap on PCS leads to packets forwarding failure.
The tunnel IP by default is 10.200.200.200.
So if I traceroute a packet sent from my machine to a network routed through PCS, the packet is sent first to 10.200.200.200. Then PCS routes it according to its table.
There is no overlap between the wifi network and the vpn ip pool...
Might there be a transitivity problem (intrinsic to AWS) stopping my VPN flow?
Because from AWS, I can resolve DNS queries normally on my PCS appliance. I can "telnet msftconnecttest.com 80" and get a successful connected. I am pushing the correct DNS settings via VPN Tunneling > Connection Profiles. So the Pulse client is correctly configured.
As @zanyterp rightly pointed out, do you have a route on the AWS cloud to point all traffic destined to 192.168.1.0/24 (VPN IP pool) will be forwarded to 10.100.100.1 or whatever the internal port IP address of the VPN appliance?
If there is no such route, that would lead to reverse route issue i.e. client is able to reach the destination servers through VPN server's default gateway, however the destination servers are not able to reach its way back to client.
Ideally the traffic flow will be like,
Client sends a DNS query to 184.108.40.206
Client (192.168.1.10) >> VPN server tunnel interface (10.200.200.200) >> Makes routing decision based on destination address (220.127.116.11) >> Sends the traffic to it's internal port default gateway >> Several hops / NAT / PAT (Internet) >> Reaches 18.104.22.168 DNS server.
22.214.171.124 sends the DNS response to client
DNS response reaches the VPN server's default gateway >> Checks it's routing table >> if a valid route is present stating that any traffic destined to 192.168.1.0/24 network will be forwarded to VPN server internal port IP address >> VPN server internal port recieves the return traffic >> forwards it back to client IP address.