Ghost Solution Suite

I'm surprised that the IP of the VPN adapter is a problem, and as Orah suggested I'd appreciate a change to see the effect on the client logfiles (you're welcome to zip them up and e-mail them to me at nigel dot bree at gmail dot com if you don't want to edit down an excerpt to post).

Something that has occasionally been a problem with VPN adapters in the past is that some of them are coded in a somewhat unusual way. Often, tunneling VPN pseudoadapters are written to emulate Ethernet adapters, and some are coded to return a fictitious fixed Ethernet MAC address. Prior to GSS2 these things were a problem because they could cause the clients to be misidentified, but I don't expect that to be a problem for GSS2.

It's probably also a good thing if you can tell us what VPN software you are using, since it's best if we can replicate your problem here by setting up the same software in our labs.

Hmm. Actually, one thing I've been meaning to do is change the way it gets that IP for the client's log, because what is being printed there now is just the result of calling the old gethostbyname() API and printing the first address it gives back. Nowadays the client does have code in it to work out exactly which of the network interfaces is being used to talk to the server (and thus, what the most appropriate IP address to print in the log is) but it's not yet hooked up to the printing code.

So, what you're seeing in the log is in one sense just a cosmetic bug, and that log excerpt seems to be showing that the main client code per se is fine. There obviously is a real problem but I think it's lurking a little deeper, and my intuition is that it's the configuration collection code (which lives in a plugin file called MACHCONF.DLL that both the client and server use) that has the real problem; it may be having trouble trying to read the settings for the VPN adapter for some reason.

What version of the Nortel VPN client are you using (I'm assuming that the client OS is XPSP2, by the way)? When I last used their Extranet Access Client some years ago, I recall that it used to properly disable the VPN adapter rather than leave it active but fall into the Ethernet autoconfiguration system, which is what is happening for you. It may be that there's some design changes in different versions of the VPN code to match the changes in different Windows editions, and I'd like to make sure that we use the same version to reproduce your situation more exactly.

If you could e-mail me the full client log that'd be helpful, too. In the meantime we'll try and get hold of various EAC client versions and experiment with them.

Thanks for that. Something is definitely a little unusual with your Nortel install - I tried a 6.01 version of the VPN client and it worked the same way I remember it when I last actually used it for real - the IPSECSHM adapter has DHCP (and thus autoconfiguration) disabled, and is set to 0.0.0.0 when the VPN is not active. More importantly, I could collect the configuration of the client just fine.

It's possible that our code is getting upset because something isn't quite right in the linkage between the settings in the registry for the IP adapters in your client. I'm not sure if that's the case based on the log you sent, but it seems like the best lead to follow; I'll send you a link to a file that can call MACHCONF.DLL directly so I can take a look in detail at what might be upsetting it.

As to uninstalling the stray adapter, probably the easiest way is to run the Device Manager MMC applet (you can do this by running "devmgmt.msc" from the "Run..." option in the start menu) and choosing "Show Hidden Devices" from the "View" menu. If you do this, the Nortel adapter will show up in the "Network adapters" list and you can uninstall it from there.