GVC Stuck at Acquiring IP: It Is Not a Password Problem

Global VPN Client sits at Acquiring IP, and the reflex is to retype the password or reinstall the client. Neither touches the stage that failed. Authentication completed before the client ever asked for an address, so the credential is not what is holding you at that line. What is holding you there is a DHCP exchange that has not finished, and it can stall in three different places.

Authentication and address assignment are separate stages

GVC first proves who you are, then requests the settings for its virtual adapter according to the policy assigned to your connection. Those are sequential steps with different failure signatures. A bad credential usually fails earlier, with an authentication or negotiation message rather than the address line.

That ordering explains why a password reset, a new local user or a reinstall changes nothing here. The client has already been authorized; it is now waiting for a lease that the gateway or its DHCP partner has to supply. Even a policy that permits the user but assigns no address range produces exactly this screen.

So the first useful question is not "are the credentials right" but "which policy was assigned, and what does that policy say about virtual-adapter addressing". Read the effective configuration for that connection rather than a colleague's working screenshot.

Where the lease actually comes from

Two models are common. The firewall can run a DHCP scope for VPN clients itself, or it can relay the request to an external DHCP server on the internal network. The model determines which logs matter and which owner to call.

In the internal model, check that the scope still exists, belongs to the right interface, and has free leases. An exhausted scope produces a client that authenticates perfectly and never receives an address, and the gateway log may only show the request. In the relay model, the relay target, the route back to the VPN client range, and any internal DHCP authorisation all have to line up.

Write down which model your deployment uses before you test anything. Half the conflicting advice online assumes the other one.

A tunnel can be up and still drop the lease

An established control connection proves that the negotiation worked, not that tunneled data passes both ways. The DHCP exchange needs request and reply to survive the data path, which is where encryption settings, policy for the VPN zone and MTU problems live.

NAT traversal advice is the clearest example of context mattering. Some paths need it enabled, others work only with it off, and the intervening NAT plus the negotiated connection decide which. Changing it blindly while also changing client settings means you will not know which change produced the result. Record the negotiated path and the evidence before you alter encapsulation.

Restarting the home router belongs in the same category. It sometimes clears the symptom, but it does not identify why the lease failed, and the problem returns on the next connection.

Walk the lease path in order

Start at the adapter and work outward, so each step can only fail for one reason:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

A 169.254.x.x address means the adapter exists and received no reply at all, which points at the lease source or the data path. A correct address in the VPN range with the wrong DNS entries is a different fault: the lease worked and the policy supplied incomplete settings. An adapter that never appears means the client did not get as far as creating it.

Once a lease appears, try the actual resource rather than declaring victory at the address line. If file or intranet access still fails, keep the successful lease as evidence and move on to name resolution or policy, because you have left the original fault behind.

SonicWall's note on the virtual adapter lists several separate branches, and its older screenshots should not be read as the current menu map. Use it to confirm the stage you reached, not as a checklist to apply wholesale.