"VPN Split-Tunneling" disabled forces wifi to disconnect

[[email protected]]

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

tcp://*:*

udp://*:*

icmp://*:*

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 8.8.8.8 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.

Thanks,

Ray.

[tony.f]

Hello Ray,

Sorry for the tardy response.

I have just done your test. What I noticed is the following:

• I can reach my intranet just fine. No problems there.
• But my wifi is down: Tcpdump shows that all attempts to communicate with internet resources are being blocked on the DNS packet level. I see queries with destination the DNS I configured PCS with, but I see no DNS resolution.

Regards,

Tony

[[email protected]]

No worries..@tony.f Check your PM inbox.

[[email protected]]

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?

Thanks,

Ray.

[tony.f]

Hello Ray,

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.

[zanyterp]

do you have a route on your network to point 192.168.1.0 to 10.100.100.1 (or whatever your VPN IP is)?
is your wifi network also 192.168.1.0/24? if your VPN tunneling IP range is the same as your local range, that will cause problems (and since a high percentage of default home WiFi networks are on that range, that may be a problem).

[tony.f]

Hello @zanyterp,

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. 

Regards,

Tony

[[email protected]]

Hi @tony.f

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 8.8.8.8 

Client (192.168.1.10) >> VPN server tunnel interface (10.200.200.200) >> Makes routing decision based on destination address (8.8.8.8) >> Sends the traffic to it's internal port default gateway >> Several hops / NAT / PAT (Internet) >> Reaches 8.8.8.8 DNS server.

8.8.8.8 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.

Thanks,

Ray.

[zanyterp]

Thank you for the further information, @tony.f
yes, if your PCS is in the AWS cloud, i do not believe split tunneling disabled can be used (i know that is a limitation of azure and am guessing it is the same for AWS). i have not heard/seen where it disconnects the adapter in either scenario, though.
i would recommend opening a case with support for further investigation
[email protected], thank you for the detailed write up