WWW not available after VPN

[IFRs]

Sometimes I use a VPN to establish a connection to my work server.

The problem is that after I disconnect from the VPN, the

http://www is

unavailable until I reboot.

When I look at IPCONFIG /ALL, there is a PPP adapter that does not go away. The Ethernet adapter for the LAN data does not change. See below for the PPP adapter that does not go away:

I have tried IPCONFIG /RELEASE and /RENEW to no avail.

IPCONFIG when connected to the VPN:

PPP adapter ATI VPN:



Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface

Physical Address. . . . . . . . . : 00-53-45-00-00-00

Dhcp Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 10.0.10.1

Subnet Mask . . . . . . . . . . . : 255.255.255.255

Default Gateway . . . . . . . . . : 10.0.10.1

DNS Servers . . . . . . . . . . . : 10.0.0.11

10.0.0.9

Primary WINS Server . . . . . . . : 10.0.0.11

Secondary WINS Server . . . . . . : 10.0.0.9


IPCONFIG after disconnected from the VPN:

PPP adapter ATI VPN:



Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface

Physical Address. . . . . . . . . : 00-53-45-00-00-00

Dhcp Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 0.0.0.0

Subnet Mask . . . . . . . . . . . : 0.0.0.0

Default Gateway . . . . . . . . . : 192.168.1.101


IPCONFIG for Ethernet LAN shows a default gateway as 192.168.1.1 all the time.

 

[bcastner]

Store NETSH profiles of the machine prior to creating the VPN connection,

Then you can use a batch file or shortcut to do the restore to that state:

http://www.petri.co.il/configure_tcp_ip_from_cmd.htm

 

[John Lewis]

Hmmm. . . . Don't think the netsh thing would be my first solution. It should work, if all else fails, but it shouldn't be nearly that complicated.

When you drop the VPN connection, the ATI VPN ppp adapter should go away. Something isn't happenning right. I would contact your vendor as this seems like a legitimate bug.

Haven't heard of ATI, can't find anything of any use on the net. Looks like they are a Checkpoint VASP. Doesn't mean a lot. It would indicate that they probably have a good solution overall, but the software from their end may not be as mature as some others. I would think their market position should make them open to hearing about problems.

 

[IFRs]

Each of the following things was tried after a reboot, double-click on the VPN and disconnect the VPN:

I tried the Netsh thing, it hung the DOS session. I tried to disable the LAN (in Network Connections), that hung also. I tried to repair the LAN (in Network Connections), that hung also. If I double-click on the ATI VPN icon a second time, it hangs.

ATI is my abbreviation for my company name. The VPN was set up on my comuter by using the "New Connection Wizard", using all the defaults and filling in the IP, name and password.

My PC is:
Dual Xenon 2.2Ghz
2 Gig RAM
(2) 30 Gig 15,000 rpm SCSI drives in RAID 0
(2) 30 Gig 15,000 rpm SCSI drive backup
(1) 9 Gig 10,000 rpm SCSI drive old data
ATI Fire GL video card
CD RW, DVD, floppy
Intel based NIC on the motherboard
Linksys router sharing 2-way cable
Zonealarm firewall
PcCillin anti-virus
Windows XP Pro clean install
Office 2003
All software fully updated and patched

 

[John Lewis]

Sorry, should have caught on to where the ATI came from, wasn't thinking fast enough.

There was a problem with XP behaving this way, but as far as I know it only applied to Connection Manager nodes, not Connection Wizard nodes. It was fixed in SP1, so I don't think that should be the problem, since you are all packed up.

PcCillin in particular does some weird things to TCP/IP, I would start with eliminating that. If I had to place a bet, that's where it would be.

Next step would be to eliminate Zonealarm, although I would be a bit surprised if that is the problem.

The earlier problem with XP and CM nodes involved the user making connections not having proper permissions to enumerate the connecitons in the registry, the problem did not apply to the admin account. Although this only applied to CM nodes at the time and is supposed to be fixed, you might want to try logging in as Administrator and trying the connection just to rule it out.