|
Posted by Fred Marshall on August 23, 2005, 12:30 pm
If you were Registered and logged in, you could reply and use other advanced thread options
Scott,
Thanks. I did resolve it by reinstalling the VPN client.
Your description of how things work is helpful!
Fred
I don't know why I didn't see your post until today.... ?
> Did you get your issue resolved?
>
> Packets will use an interface based on the routing table. (type 'route
> print' at a command prompt)
> Generally speaking when the VPN is connected it will add a route to the
> table. So say your local LAN is 192.168.1.X/255.255.255.0 and the Corp
> office is 10.1.x.x/255.255.0.0 There should be a route added in the table
> that tells the packets to use the VPN interface for any packet destined to
> the 10.1.x.x network.
>
> Now the VPN termination point might also be blocking ports and only
> allowing specific ports. You will have to be sure that the ports you are
> working with (80, 443) are both open for the VPN Clients.
>
> I always try to use IP addresses of the servers that I'm testing with so I
> don't have to deal with name server issues at the same time. Once the IP
> Traffic is working well, then deal with how the names are resolved.
>
> Name resolution is a unique issue with VPNs too. If you access
> www.domain.com without a VPN Connection. it uses your Public interface and
> DNS Server to get the address if it exists. If the name is also on the
> internal network DNS then it will have 2 addresses, the public IP and the
> Private IP. So now you bring up your VPN and try to access the same
> server... Well your machine already resolved the address to the public IP
> and will use that IP and not the internal IP. you will need to have it
> flush the DNS Cache resolver (ipconfig /flushdns) to clear out the old DNS
> entry and then query again. Even if you cant Ping the device (blocked
> ports or what have you) you can still ping the name to be sure that it
> resolves to the proper address
>
> Scott<-
>
>>I should add that the behavior on the "broken" system is identical to
>>behavior I see on a computer that doesn't have the VPN installed / running
>>/ connected.
>>
>> I can access all the same pages from another, unrelated computer *and* I
>> cannot access the *same* pages on the computer with the VPN client
>> installed. This suggests there's something broken with the VPN
>> configuration on the target client computer.
>>
>> Fred
>>
>>
>>> I'm trying to get one XP system to access web pages using a Cisco VPN
>>> client.
>>> The system had been working fine. Details are below.
>>>
>>> One question I have is:
>>> Given that we see the Ethernet NIC interface and given that we see the
>>> VPN client as a network interface:
>>> How does the sytem decide which of these "interfaces" to use in
>>> supporting things like Internet Explorer?
>>> It *appears* that all the interfaces are working but those pages that
>>> require the VPN aren't coming up. Thus my (probably dumb) question.
>>>
>>> Presently we can see normal web pages both http and https. But we
>>> cannot access an https page that probably requires connection via the
>>> VPN.
>>>
>>> So, my other question is:
>>> How might this be fixed?
>>> I'm tempted to reinstall the VPN client, repair the TCP/IP stack, ....
>>>
>>> Any suggestions regarding both questions would be greatly appreciated.
>>>
>>> Thanks,
>>>
>>> Fred
>>>
>>> *****Background:
>>> We're working on a customer's system with *no* technical reference
>>> information or support.
>>> It's rather strange indeed but I'm sure we'll figure it out.
>>> I could use some advice / help:
>>>
>>> The system has the following:
>>>
>>> A Westell DSL Modem - working fine.
>>> (Initially, the modem was set up to be dialed by PPPOE software in the
>>> PC. I changed this so that the modem will dial and stay connected by
>>> itself. Maybe this was a mistake but I don't see how.)
>>>
>>> Ethernet NIC: as normal, an ethernet NIC shows up as a network
>>> interface.
>>>
>>> PPPOE interface: IF the PPPOE software is started, then it shows up as
>>> an interface. But now that the modem is automatic, this software
>>> doesn't do anything. So, I just don't start it up at all. I've seen
>>> lots of systems transitioned from using "dialing" software to simply
>>> letting the modem do the connection work - so I'm very used to this
>>> part.
>>>
>>> There is a Cisco VPN client installed on the computer. I'm not so used
>>> to this.....
>>> When the VPN client is started, it connects. So far this seems good.
>>>
>>> So, the current network interfaces showing are:
>>> Ethernet NIC - connected with IP address DHCP from the modem.
>>> VPN "interface" - connected with IP address that must be coming from the
>>> other end of the VPN...
>>> PPPOE interface - not connected / used.
>>> Dialup connection - not connected / used.
>>>
>>> For the critical purpose of the sytem, Internet Explorer 6 is being used
>>> for all interfacing - to interactive web pages.
>>> The customer reports that the distant servers recently switched from
>>> http to https pages.
>>> After this was done, they report that one of the client computers
>>> stopped connnecting to the pages.
>>> So, our task is to get it working again.
>>> (Because all other clients in this system are working, we might assume
>>> that the switch to https has *nothing to do* with the problem).
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
| 
NewsGroups 
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map