VPN client adds wrong route to local route table

Clients are WinXP sp2, VPN server is Win 2003.

Clients are on 10.30.0.x
Server is on 192.168.10.x network. Its IP is 192.168.10.10.

When I make a VPN connection from a 10.30.0.x host to the 192.168.10.10
VPN server, I get a weird route in the client's routing table.

It adds a route for the *server* IP, with the client's LAN gateway as
the gateway.

Before VPN Connection:
Active Routes:
Network Destination Netmask Gateway Interface
0.0.0.0 0.0.0.0 10.30.0.1 10.30.0.11
10.30.0.0 255.255.255.0 10.30.0.11 10.30.0.11
10.30.0.11 255.255.255.255 127.0.0.1 127.0.0.1
10.255.255.255 255.255.255.255 10.30.0.11 10.30.0.11
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
224.0.0.0 240.0.0.0 10.30.0.11 10.30.0.11
255.255.255.255 255.255.255.255 10.30.0.11 10.30.0.11
Default Gateway: 10.30.0.1

After connection:
Active Routes:
Network Destination Netmask Gateway Interface
0.0.0.0 0.0.0.0 10.30.0.1 10.30.0.11
10.30.0.0 255.255.255.0 10.30.0.11 10.30.0.11
10.30.0.11 255.255.255.255 127.0.0.1 127.0.0.1
10.255.255.255 255.255.255.255 10.30.0.11 10.30.0.11
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1
192.168.10.0 255.255.255.0 192.168.10.27 192.168.10.27
192.168.10.10 255.255.255.255 10.30.0.1 10.30.0.11
192.168.10.27 255.255.255.255 127.0.0.1 127.0.0.1
192.168.10.255 255.255.255.255 192.168.10.27 192.168.10.27
224.0.0.0 240.0.0.0 10.30.0.11 10.30.0.11
224.0.0.0 240.0.0.0 192.168.10.27 192.168.10.27
255.255.255.255 255.255.255.255 10.30.0.11 10.30.0.11
255.255.255.255 255.255.255.255 192.168.10.27 192.168.10.27
Default Gateway: 10.30.0.1

Notice in the After table that there is a route for 192.168.10.10/32
directed at 10.30.0.1. The result is that I can ping anything on the
192.168.10.x network *except* the server on 192.168.10.10.

I've tried this on an XP client to a Win2000 VPN server and did not
experience the same issue. It seemed to just start happening here.

Any help is appreciated.

Also thought I'd mention that changing Use Default Gateway on Remote
Network in the VPN client config makes no difference to the route
table.

That looks correct to me. The client should have a host route to the VPN
server's "external" IP through the LAN gateway. That is where the encrypted
and encapsulated data has to go for the VPN tunnel to work. You should be
able to ping the server through the tunnel using its "virtual" IP. You can
see what that is from the client. If you click on the connection icon it
will show you both the client and server "virtual" IP addresses.

The routing table you gave was probably made with the "use default
gateway.." box cleared. Exactly what that setting does is explained in
KB254231 .

snowdog_2112 wrote:
> Also thought I'd mention that changing Use Default Gateway on Remote
> Network in the VPN client config makes no difference to the route
> table.

The problem I have is that the DNS and WINS settings that get assigned
on the PPP connection are the 192.168.10.10 address of the VPN server,
so any nslookups or WINS lookups fail because those requests are
directed out the client's LAN gateway.

What you're suggesting is that any traffic from the VPN client to the
VPN server is sent outside the tunnel. Since only the VPN ports are
open on the router, those operations fail. Yet if I direct an nslookup
to another server on the network (on the same segment as the VPN
server), the lookups work.

I think I'm missing something.

Also, as I mentioned, I made a VPN connection from another client to a
different VPN server and did not get a route for the VPN server -- just
the route for the private network with a gateway of the PPP ip.

Please let me know if I'm missing something here.

The client usually gets the DNS and WINS addresses which are configured
on the RRAS server. Does your RRAS server point to its 192.168.10.10 address
for these?

snowdog_2112 wrote:
> The problem I have is that the DNS and WINS settings that get assigned
> on the PPP connection are the 192.168.10.10 address of the VPN server,
> so any nslookups or WINS lookups fail because those requests are
> directed out the client's LAN gateway.
>
> What you're suggesting is that any traffic from the VPN client to the
> VPN server is sent outside the tunnel. Since only the VPN ports are
> open on the router, those operations fail. Yet if I direct an
> nslookup to another server on the network (on the same segment as the
> VPN server), the lookups work.
>
> I think I'm missing something.
>
> Also, as I mentioned, I made a VPN connection from another client to a
> different VPN server and did not get a route for the VPN server --
> just the route for the private network with a gateway of the PPP ip.
>
> Please let me know if I'm missing something here.

That's correct. The VPN server is the AD server and acts as DNS/WINS.
There is another DC on 192.168.10.9 that is running DNS and WINS.

>From the VPN connection on the client, I can:

nslookup 192.168.10.10 192.168.10.9
....and get a valid response, but

nslookup 1921.68.10.10 192.168.10.10
....fails. I'm assuming because the traffic is going to 10.30.0.1 over
the client's 10.30.0.11 interface because of that route on the client.


10.30.0.1 is blocking all but 1723, GRE and ICMP (I can, incidentally,
ping 192.168.10.10 with the VPN connected).

As a test, I denied ICMP at the router and pings to 192.168.10.10
failed.

Incidentally, there is only one router between these segments -- in
fact, the 10.30.0.1 is one ethernet on the router and 192.168.10.1 is a
different ethernet on that same router. I don't see how that would
cause this, but it occurred to me that it is worth mentioning.

You could try manually configuring the DNS and WINS addresses on the
clients to point to the other server.

snowdog_2112 wrote:
> That's correct. The VPN server is the AD server and acts as DNS/WINS.
> There is another DC on 192.168.10.9 that is running DNS and WINS.
>
>> From the VPN connection on the client, I can:
>
> nslookup 192.168.10.10 192.168.10.9
> ...and get a valid response, but
>
> nslookup 1921.68.10.10 192.168.10.10
> ...fails. I'm assuming because the traffic is going to 10.30.0.1 over
> the client's 10.30.0.11 interface because of that route on the client.
>
>
> 10.30.0.1 is blocking all but 1723, GRE and ICMP (I can, incidentally,
> ping 192.168.10.10 with the VPN connected).
>
> As a test, I denied ICMP at the router and pings to 192.168.10.10
> failed.
>
> Incidentally, there is only one router between these segments -- in
> fact, the 10.30.0.1 is one ethernet on the router and 192.168.10.1 is
> a different ethernet on that same router. I don't see how that would
> cause this, but it occurred to me that it is worth mentioning.

I guess I'd be more interested in knowing how to fix the current issue
-- I don't think I should be getting that route in the first place.
I've not seen that in other VPN configurations I have done.