- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
11-06-2021 04:48 AM
Hi Everyone,
I need your help as I'm facing a very strange issue with GlobalProtect, the VPN used in my company.
When I'm working from home I switch on my PC which is already connected to an ethernet cable: GlobalProtect connects almost immediately (usually to Europe Primary) and I'm able to access my company network drives, folders and remote desktops. However every operation is very slow: network folders take a lot of time to open on explorer, when I launch a RDP connection it takes a lot of time to log onto the the virtual machine and, above all, when I need to connect to oracle databases through ODBC it takes a lot of time to resolve such connections.
Below the screenshot of the IPConfig (Ethernet Connection 3): look at the IPv6 and Temporary IPv6 addresses and keep them in mind.
If I disconnect the ethernet cable, activate the WiFi connection (from same Router and same ISP) and wait for GlobalProtect to reconnect then everything start to work as expected at a much faster speed: network drives open with a blink of an eye, ODBC Connections are resolved immediately and virtual machines are launched istantly.
As you can see from the screenshot below (Wireless LAN Adapter), now the the IPv6 and Temporary IPv6 addresses have disappeared!
As I don't want to use WiFi because signal is very weak, I disconnect it and reconnect the Ethernet Cable. I wait for GlobalProtect to reconnect and everything works just fine as it was under WiFi.
Infat now the Ipconfig looks different with respect to the first cabled connection when I switched on the PC: the Ethernet 3 does not have the IPv6 and Temporary IPv6 Addresses and it mirrors the settings of the Wireless LAN Adapter seen just above.
I really need your help to sort this issue out because it is very frustrating: each morning I need to connect with Lan Cable, then disconnect it, switch on WiFi, wait for GlobalProtect to connect, then switch off WiFi and finally connect LAN Cable again.
What can I suggest my IT department to do?
I'm not a technician but I suspect the issue is caused by this IPv6 Addresses that are wrongly assigned when the first connection to VPN is done through Ethernet Cable.
Many thanks in advance,
Gianluca
11-07-2021 01:05 AM
Hi
I have some thoughts about debugging this a little further:
1. Can you try to disable IPv6 binding on your OS? In windows run ncpa.cpl, right click & properties of 'PANGP virtual Ethernet adapter' (or Ethernet 3) and unselect IPv6 binding. This should completely remove IPv6. Reboot and test.
2. Bring to your IT's knowledge this configuration:
In your Globalprotect portal configuration, 'Resolve All FQDNs Using DNS Servers Assigned by the Tunnel (Windows Only)' option if set to 'Yes' - will enforce the client machine to resolve all the DNS queries through the tunnel.
If set to 'No'. This allows Windows endpoints to send DNS queries to the DNS server set on the physical adapter if the initial query to the DNS server configured on the gateway is not resolved. This option retains the native Windows behavior to query all DNS servers on all adapters recursively but can result in long wait times to resolve some DNS queries.
The first item is on your workstation and can be tested locally but the second item could potentially affect all users. I think your IT can see if this is the cause of your issues by nslookup commands on your workstation in ETH/WiFi mode. In addition - check the firewall logs to see if and where your IPv6 packets go 🙂
Hope this helps,
Shai
11-07-2021 01:05 AM
Hi
I have some thoughts about debugging this a little further:
1. Can you try to disable IPv6 binding on your OS? In windows run ncpa.cpl, right click & properties of 'PANGP virtual Ethernet adapter' (or Ethernet 3) and unselect IPv6 binding. This should completely remove IPv6. Reboot and test.
2. Bring to your IT's knowledge this configuration:
In your Globalprotect portal configuration, 'Resolve All FQDNs Using DNS Servers Assigned by the Tunnel (Windows Only)' option if set to 'Yes' - will enforce the client machine to resolve all the DNS queries through the tunnel.
If set to 'No'. This allows Windows endpoints to send DNS queries to the DNS server set on the physical adapter if the initial query to the DNS server configured on the gateway is not resolved. This option retains the native Windows behavior to query all DNS servers on all adapters recursively but can result in long wait times to resolve some DNS queries.
The first item is on your workstation and can be tested locally but the second item could potentially affect all users. I think your IT can see if this is the cause of your issues by nslookup commands on your workstation in ETH/WiFi mode. In addition - check the firewall logs to see if and where your IPv6 packets go 🙂
Hope this helps,
Shai
11-07-2021 02:10 AM
Hi Shai,
thank you very much for your reply.
I've tried solution 1. and it worked! First I tried disabling the IPv6 Protocol on PANGP virtual Ethernet adapter (which is Ethernet 2 on my configuration) and issue was still present. Then I also disabled IPv6 Protocol on the 'real' connection, so Ethernet 3 and this time it worked!
Now the Ipconfig looks this way:
Should I leave it as it is or the fact of disabling IPv6 can cause some issues in the future (security related above all)?
Thanks again
11-07-2021 02:28 AM
Hi
If this is a work computer - I think you should consult your IT because IPv6 is enabled by default - if you have this issue maybe other workers have it.
Shai
11-30-2021 01:39 PM
Turning off IPv6 binding on one interface should not turn it off on another.
So, turning it off on the GP interface (Ethernet 2), that should not turn it off on the physical LAN Ethernet (Ethernet 3) yet comparing the last screenshot to the first few, IPv6 is completely disabled.
But one thing I notice from the first post is that the Ethernet 3 seems to be getting issued an IPv6 from the router from somewhere in addition to its link-local IPv6 address, first with what might be a DHCP suffix as the temporary IPv6, then switching to MAC based IP. Not sure if IPv6 prefix of FDD7 has any IP type significance like FE80 has.
11-30-2021 01:50 PM
I bet too that because of the IPv6 on your local network that is not link-local, much of the traffic that should be going over the tunnel, such as DNS requests, isn't going over it but rather to the internet through the IPv6 configuration.
You could even be getting less than possible internet performance with that IPv6 setup.
Since most probably do not have a 'legitimate' IPv6 network configuration at our homes, I don't think this is a widespread issue that his company can fix.
As for the temporary IPv6 address, I found this which indicates Windows can generate random generated IPv6 suffixes for purposes of privacy. Seems it does this along with the one based on MAC.
https://superuser.com/questions/703915/why-does-my-windows-have-hundreds-of-temporary-ipv6-addresses
11-30-2021 02:09 PM
Hi Dan,
thank you for your contribution.
My internet data provider just switched to an IPv6 configuration as they’ve ran out of IP4 addresses. In fact since this update (2 weeks ago) the solution provided by ShaiW (disabling IPv6 under Ethernet 3 windows configuration) no longer works: I had to re-enable it and the issue for which I’ve opened this post came back again.
I’ve contacted my IT dept and told them to check whether the option “'Resolve All FQDNs Using DNS Servers Assigned by the Tunnel (Windows Only)’” is set to yes/no on GP as suggested by ShaiW (I’m still waiting for a reply though).
By the way, I still can’t understand why I have such issue just when connecting to GP just after PC boot with Ethernet Cable while I have not this issue at all when connecting through wi-fi or with Ethernet after switching from wi-fi. It’s weird!!
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!