VPN connection works, lan access fails

[Doug Leece]

Hi all,
I have rebuilt this config a dozen times and scoured the
news groups but I can't find the solution. Using SBS 2003
and the PPTP clients for XP or 2000 I cna connect to the
RAS server just fine. I pick up a local address from the
DHCP pool and I can ping the SBS server dedicated address,
my new PPTP ip address and the IP address that shows up in
RRAS manager as internal. I cannot connect to anything
else in the private lan though. If i remote desktop onto
the RRAS box then I can access all things in the lan just
fine.

This is a dual NIC server with one disabled, all
connections pass through a router. I also have this
working in two other sites, only different is I used the
Dell SBS2003 server load instead of MS original. Any
ideas, it looks like routing but netstat -rn indicates
things are as they should be.

 

[Bill Grant]

Is it a routing or a name resolution problem? Can you ping a LAN machine
by using its IP address?

If you can't even ping by IP, are the remotes receiving IP addresses in
the same subnet as the LAN machines?

 

[Doug Leece]

Hi Bill,

Sadly we are broken down at the IP level, I can't connect
to any devices in the private subnet. The SBS/RRAS server
is in the same subnet as the servers I am trying to
connect to via IP address. I just finished loading up
network monitor and I can see from the logs that the
source IP of the PPTP client is 192.168.100.161, I have a
route from 192.168.100.161 to 192.168.100.162 on the RRAS
box. I can even ping 192.168.100.162 from a server in the
private LAN, ( eg 192.168.100.15/24) but from the PPTP
client and cannot ping 192.168.100.15.

I suspect I need to enable routing someplace but I have
already turned it on in the RRAS setup. ( Disabling
routing to LAN doesn't seem to make any difference either.)

Thanks again for any thought s you might have, this one is
really strange.
Doug Leece

 

[Bill Grant]

If they are all in the same IP subnet, you shouldn't need routing
enabled anywhere and you shouldn't need to add any routes! There is no
"real" routing going on because they are all in the same IP subnet. The VPN
server should just forward the traffic on to the LAN, and do proxy ARP on
the LAN to pick up replies for the remotes. As far as TCP/IP is concerned,
they are all in the same IP subnet and on the same segment.

Are the servers on a switched network? Some switches don't handle proxy
ARP the same way as standard Ethernet hubs. If that is the problem, you
might need to put the remotes in a different IP subnet and route them
through the VPN server. (ie enable IP routing on it and make sure that the
traffic for the remote subnet is routed through the LAN to the VPN server if
it is not the default gateway of the LAN).

 

[Guest]

If they are all in the same IP subnet, you shouldn't need routing
enabled anywhere and you shouldn't need to add any routes! There is no
"real" routing going on because they are all in the same IP subnet. The VPN
server should just forward the traffic on to the LAN, and do proxy ARP on
the LAN to pick up replies for the remotes. As far as TCP/IP is concerned,
they are all in the same IP subnet and on the same segment.

Are the servers on a switched network? Some switches don't handle proxy
ARP the same way as standard Ethernet hubs. If that is the problem, you
might need to put the remotes in a different IP subnet and route them
through the VPN server. (ie enable IP routing on it and make sure that the
traffic for the remote subnet is routed through the LAN to the VPN server if
it is not the default gateway of the LAN).

 

[Bill Grant]

The extra IP you see is indeed the internal interface. As soon as the
first remote user connects, the internal interface acquires an IP address.
This interface is the server end of the point-to-point connection between
client and server (ie it is the logical end of the VPN tunnel).

HI again Bill,

I agree with your routing assessment though I had found a lot of MS
doscumentation that indicated you need routing to access private lans
from VPN. I always figured local is local and arp requests should
handle tings but I considered there may be a need to forward packets
from the PPTP daemon virtual IP to the physical. The routes below
indicate that something like that could be happening.

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\Documents and Settings\wadmin>netstat -rn

IPv4 Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x10002 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
0x10003 ...00 11 43 5a aa d6 ...... Intel(R) PRO/1000 MT Network
Connection
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface
Metric
0.0.0.0 0.0.0.0 192.168.100.254 192.168.100.12
1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
1 142.179.156.47 255.255.255.255 192.168.100.254 192.168.100.12
1 192.168.59.10 255.255.255.255 192.168.100.254 192.168.100.12
1 192.168.100.0 255.255.255.0 192.168.100.12 192.168.100.12
10 192.168.100.12 255.255.255.255 127.0.0.1
127.0.0.1 10 192.168.100.146 255.255.255.255 192.168.100.151
192.168.100.151 1 192.168.100.151 255.255.255.255
127.0.0.1 127.0.0.1 50 192.168.100.255 255.255.255.255
192.168.100.12 192.168.100.12 10 192.168.200.0
255.255.255.0 192.168.100.12 192.168.100.12 1
224.0.0.0 240.0.0.0 192.168.100.12 192.168.100.12 10
255.255.255.255 255.255.255.255 192.168.100.12 192.168.100.12
1 Default Gateway: 192.168.100.254
===========================================================================
Persistent Routes: None

Do you now why the second IP shows up once the first PPTP connection
is made? The same IP shows up as "Internal" when I am looking at the
RRAS console. From the inside LAN I can ping the SBS static IP,
known as dedicated in RRAS, and the new IP that shows up as
"internal".

Your arp question did give me a lead though, both the "internal" and
"dedicated" interfaces show up with the same MAC on the internal host
I was testing from. What was interesting is both interfaces became
unreachable as soon as I made a PPTP connection from the outside,
when the PPTP session was terminated both SBS ip's were reachable
again. If I restart the RAS service the second IP disappears until
the first PPTP connection is created.

I can understand the single "internal" IP proxying all the PPTP
sessions through to the LAN and making all traffic appear local
without stacking many IPs with the same mac in other hosts arp cache.
Is this actually how it works/supposed to behave, any good links that
cover the guts of MS pptp implementation? Still wondering why would
both IP's become unreachable as soon as a PPTP connection was made
from a remote address.

As soon as I disconnect the PPTP client connections work again so you
may be quite right about the switch causing issues. Do you know of
switches that do work?

Thanks for the lead, I'll certainly post anything I find.

Doug Leece

If they are all in the same IP subnet, you shouldn't need routing
enabled anywhere and you shouldn't need to add any routes! There is
no "real" routing going on because they are all in the same IP
subnet. The VPN server should just forward the traffic on to the
LAN, and do proxy ARP on the LAN to pick up replies for the remotes.
As far as TCP/IP is concerned, they are all in the same IP subnet
and on the same segment.

Are the servers on a switched network? Some switches don't
handle proxy ARP the same way as standard Ethernet hubs. If that is
the problem, you might need to put the remotes in a different IP
subnet and route them through the VPN server. (ie enable IP routing
on it and make sure that the traffic for the remote subnet is routed
through the LAN to the VPN server if it is not the default gateway
of the LAN).