No access to website with VPN client running now

G

Guest

For quite a few years I ran my own Windows 2000 server as a sub-domain
of a much larger domain. Eventually our IT people wanted my server
shut down for security reasons. Among other services I ran a VPN host
on my old server. Several machines at home (all XP Pro with SPs and
all updates) were clients of that VPN service. One of those machines
also hosted a website using DDNS through a DLink router and DSL
modem. I never experienced any problems with website access while the
VPN client was running on that machine -- which was just about always.

Now I am using a VPN service hosted on a machine looked after by our
systems administrator. Both VPNs were PPTP. I can see no meaningful
difference in the way I have VPN configured on my client machines at
home, including the machine that hosts the website (that machine is
connected to the router by ethernet cable and is on a fixed IP
number). After the change to the new VPN host, however, attempts to
browse it to the website are unsuccessful. The DDNS service provides
the browser with the correct IP number and the alternate port number
for IIP on my machine but the browser fails to connect. If I
disconnect the VPN client, however, the browse is successful. This
problem is new after the change to the new VPN host. I never
experienced it in all the time that I ran my own server.

Does anyone have any idea what the problem might be here -- and how to
fix it?

Thanks in advance for any help!
 
R

Robert L [MVP - Networking]

Sounds like routing issue. Posting the result of routing table here may help.

Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com
For quite a few years I ran my own Windows 2000 server as a sub-domain
of a much larger domain. Eventually our IT people wanted my server
shut down for security reasons. Among other services I ran a VPN host
on my old server. Several machines at home (all XP Pro with SPs and
all updates) were clients of that VPN service. One of those machines
also hosted a website using DDNS through a DLink router and DSL
modem. I never experienced any problems with website access while the
VPN client was running on that machine -- which was just about always.

Now I am using a VPN service hosted on a machine looked after by our
systems administrator. Both VPNs were PPTP. I can see no meaningful
difference in the way I have VPN configured on my client machines at
home, including the machine that hosts the website (that machine is
connected to the router by ethernet cable and is on a fixed IP
number). After the change to the new VPN host, however, attempts to
browse it to the website are unsuccessful. The DDNS service provides
the browser with the correct IP number and the alternate port number
for IIP on my machine but the browser fails to connect. If I
disconnect the VPN client, however, the browse is successful. This
problem is new after the change to the new VPN host. I never
experienced it in all the time that I ran my own server.

Does anyone have any idea what the problem might be here -- and how to
fix it?

Thanks in advance for any help!
 
G

Guest

Sounds like routing issue. Posting the result of routing table here may help.

Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting onhttp://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access onhttp://www.HowToNetworking.com <[email protected]> wrote in messagenews:[email protected]...

Here's the routing table:

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0xa0003 ...00 16 76 c7 dd 45 ...... Intel(R) 82566DM Gigabit Network
Connection - Trend Micro Common Firewall Miniport
0x550005 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway
Interface Metric
0.0.0.0 0.0.0.0 192.168.0.1
192.168.0.100 20
127.0.0.0 255.0.0.0
127.0.0.1 127.0.0.1 1
129.100.0.0 255.255.0.0 129.100.42.105
129.100.42.105 1
129.100.42.69 255.255.255.255 192.168.0.1
192.168.0.100 20
129.100.42.105 255.255.255.255 127.0.0.1
127.0.0.1 50
129.100.255.255 255.255.255.255 129.100.42.105
129.100.42.105 50
192.168.0.0 255.255.255.0 192.168.0.100
192.168.0.100 20
192.168.0.100 255.255.255.255 127.0.0.1
127.0.0.1 20
192.168.0.255 255.255.255.255 192.168.0.100
192.168.0.100 20
224.0.0.0 240.0.0.0 129.100.42.105
129.100.42.105 50
224.0.0.0 240.0.0.0 192.168.0.100
192.168.0.100 20
255.255.255.255 255.255.255.255 129.100.42.105
129.100.42.105 1
255.255.255.255 255.255.255.255 192.168.0.100
192.168.0.100 1
Default Gateway: 192.168.0.1
===========================================================================
Persistent Routes:
None

Route Table
 
G

Guest

That's really hard to read. Perhaps this will turn out better.

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0xa0003 ...00 16 76 c7 dd 45 ...... Intel(R) 82566DM Gigabit Network
Connection - Trend Micro Common Firewall Miniport
0x550005 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface
Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.100
20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
1
129.100.0.0 255.255.0.0 129.100.42.105 129.100.42.105
1
129.100.42.69 255.255.255.255 192.168.0.1 192.168.0.100
20
129.100.42.105 255.255.255.255 127.0.0.1 127.0.0.1
50
129.100.255.255 255.255.255.255 129.100.42.105 129.100.42.105
50
192.168.0.0 255.255.255.0 192.168.0.100 192.168.0.100
20
192.168.0.100 255.255.255.255 127.0.0.1 127.0.0.1
20
192.168.0.255 255.255.255.255 192.168.0.100 192.168.0.100
20
224.0.0.0 240.0.0.0 129.100.42.105 129.100.42.105
50
224.0.0.0 240.0.0.0 192.168.0.100 192.168.0.100
20
255.255.255.255 255.255.255.255 129.100.42.105 129.100.42.105
1
255.255.255.255 255.255.255.255 192.168.0.100 192.168.0.100
1
Default Gateway: 192.168.0.1
===========================================================================
Persistent Routes:
None

Route Table
 
G

Guest

With VPN off (and browsing to site working) it's:

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0xa0003 ...00 16 76 c7 dd 45 ...... Intel(R) 82566DM Gigabit Network
Connection - Trend Micro Common Firewall Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface
Metric
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.100
20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
1
192.168.0.0 255.255.255.0 192.168.0.100 192.168.0.100
20
192.168.0.100 255.255.255.255 127.0.0.1 127.0.0.1
20
192.168.0.255 255.255.255.255 192.168.0.100 192.168.0.100
20
224.0.0.0 240.0.0.0 192.168.0.100 192.168.0.100
20
255.255.255.255 255.255.255.255 192.168.0.100 192.168.0.100
1
Default Gateway: 192.168.0.1
===========================================================================
Persistent Routes:
None

Route Table
 
G

Guest

Bob, I want to sincerely thank you for putting me on the trail of
understanding, explanation, and solution. It's been a bit of a
learning curve on how routing tables are used but, with the help of xp
and some helptful sites on routing tables, I concluded that my problem
was arising because I was trying to verify my web from a machine that
is in the same ip pool as the vpn ips. Careful application of the
routing rules showed me that packets trying to go to the test machine
would be routed elsewhere when the vpn client was on. The solution
was embarrassingly simple--a persistent "exact match" (mask
255.255.255.255) table entry, metric 1, and all is well.

A bit of a learning curve--but I never would have gotten on the curve
without the all-important clue that this was a routing-table problem.
So many thanks indeed!!!!
 
G

Guest

Bob, I want to sincerely thank you for putting me on the trail of
understanding, explanation, and solution. It's been a bit of a
learning curve on how routing tables are used but, with the help of xp
and some helptful sites on routing tables, I concluded that my problem
was arising because I was trying to verify my web from a machine that
is in the same ip pool as the vpn ips. Careful application of the
routing rules showed me that packets trying to go to the test machine
would be routed elsewhere when the vpn client was on. The solution
was embarrassingly simple--a persistent "exact match" (mask
255.255.255.255) table entry, metric 1, and all is well.

A bit of a learning curve--but I never would have gotten on the curve
without the all-important clue that this was a routing-table problem.
So many thanks indeed!!!!
 
G

Guest

Bob, I want to sincerely thank you for putting me on the trail of
understanding, explanation, and solution. It's been a bit of a
learning curve on how routing tables are used but, with the help of xp
and some helptful sites on routing tables, I concluded that my problem
was arising because I was trying to verify my web from a machine that
is in the same ip pool as the vpn ips. Careful application of the
routing rules showed me that packets trying to go to the test machine
would be routed elsewhere when the vpn client was on. The solution
was embarrassingly simple--a persistent "exact match" (mask
255.255.255.255) table entry, metric 1, and all is well.

A bit of a learning curve--but I never would have gotten on the curve
without the all-important clue that this was a routing-table problem.
So many thanks indeed!!!!

And, of course, this explains why I never had this problem on my old
server--I used a set of "dummy" ips not at all like the ips on the
work domain!
 
R

Robert L [MVP - Networking]

Thank you for the feedback.

Bob Lin, MS-MVP, MCSE & CNE
Networking, Internet, Routing, VPN Troubleshooting on http://www.ChicagoTech.net
How to Setup Windows, Network, VPN & Remote Access on http://www.HowToNetworking.com
Bob, I want to sincerely thank you for putting me on the trail of
understanding, explanation, and solution. It's been a bit of a
learning curve on how routing tables are used but, with the help of xp
and some helptful sites on routing tables, I concluded that my problem
was arising because I was trying to verify my web from a machine that
is in the same ip pool as the vpn ips. Careful application of the
routing rules showed me that packets trying to go to the test machine
would be routed elsewhere when the vpn client was on. The solution
was embarrassingly simple--a persistent "exact match" (mask
255.255.255.255) table entry, metric 1, and all is well.

A bit of a learning curve--but I never would have gotten on the curve
without the all-important clue that this was a routing-table problem.
So many thanks indeed!!!!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

vpn client share access 6
VPN server without domain controller 0
vpn 1
VPN Server does not allow multple VPN connection 4
newbie: VPN and IP mismatch 6
VPN Issue 1
VPN Client 1
slightly OT: vpn hardware 4

Top