Strange VPN problem (was: Two servers, one VPN)

[Michael A. Covington]

Let me add another newsgroup and restate the whole problem from the top.

We are on a departmental LAN in a university, which is part of the Internet.
No NAT.

We had one Windows 2000 (later 2003) server, on which we enabled VPN in
order to allow users to get to their files from elsewhere on the Internet.

At the time, we didn't check (or care) that the VPN didn't enable people to
see the rest of the LAN.

We have now added a second server and moved onto it some of the files that
people need to access.

When users connect to the VPN, they can get to Server 1 but not Server 2 or
anything else on the LAN.

Examples:

net view server1
--- list of shared resources on server1 ---

net view server2
network connection not found (or words to that effect)

What do I need to change?

I should add that server1 has only one network card in it. Am I going to
have to add a second network card even though they're both going to be
connected to exactly the same network? Do I just need to add some routing
or something?

Apart from the VPN problem, server1 and server2 have no trouble
communicating with each other; they share a lot of things constantly.

Any help would be welcome!

 

[Pawan Agarwal \(MSFT\)]

Can you let us know the topology? If the VPN server is not behind a NAT, it
requires 2 NICs. Otherwise, just a single NIC will do.

Pawan [MSFT]

 

[Michael A. Covington]

Can you let us know the topology? If the VPN server is not behind a NAT, it
requires 2 NICs. Otherwise, just a single NIC will do.

*ahhhh!* That may be it.

It is not behind a NAT. There are firewalls and switches at different
levels to keep out the riffraff, but every machine on this network is known
by its actual Internet address (128.192.something.something).

There is only one Ethernet card in the machine.

Am I right in suspecting I need two Ethernet cards, installed in the same
machine, even though both are connected to the same network? And then I'll
tell RRAS that one of them is the Internet and the other is the LAN. Right?

Will I need to add static routing information or will they already know what
they're doing?

 

[Michael A. Covington]

PROGRESS... The VPN server now has 2 Ethernet cards in it. The other
crucial step was apparently to have the VPN server give out IP addresses
that are in the same subrange as the other machines on the LAN.

*Now* I have the opposite problem than before. The VPN clients can see
everything on the LAN *except* the shared resources on the server itself.

Any ideas? Something to do with the routing table? I'm going to keep
trying the combinations and permutations...

 

[Michael A. Covington]

More progress. The only limitation is that the VPN server can't recognize
itself by its own name. Call it SERVER1. To see resources on SERVER1 I
have to use

net view 128.192.etc.etc

using the IP number of the *second* Ethernet card (the one designated as the
LAN connection). If I address it by its first Ethernet card IP number, or by
its name (whether or not fully qualified), I get "network path not found."

I can use names for all the othe rmachines on the network, e.g.: net view
server2

I'm content to leave it at this, but if there is a simple trick with the
routing table that will cure this, so much the better.

 

[Bill Grant]

It's not a routing thing, it's name resolution. You need to look at DNS
and/or WINS and see why the name of the server is resolving to the "wrong"
IP!

 

[Michael A. Covington]

It's not a routing thing, it's name resolution. You need to look at DNS
and/or WINS and see why the name of the server is resolving to the "wrong"
IP!

It's resolving to the Internet connection rather than the LAN connection.
Here's the whole picture (names changed of course):

server1.dept.school.edu resolves to the Internet connection of server1,
which I'll call 128.x.x.3.

server1 (as a Windows networking name on a VPN client) also resolves to
128.x.x.3

128.x.x.9 is the LAN connection (i.e., the second Ethernet card) of server1.

On a VPN client, "net view 128.x.x.9" works; "net view 128.x.x.3" and "net
view server1" do not.

I would like "server1" (without .dept.school.edu) to resolve to 128.x.x.9,
but "server1.dept.school.edu" to resolve to 128.x.x.3.

Is this a reasonable request? Or do I need to do some major rearranging of
names?

Would it be sufficient if I had them change the campus DNS tables so that

www.dept.school.edu is still 128.x.x.3, but
ais1.dept.school.edu becomes 128.x.x.9 ?

Would this make "ais1" (without suffixes) resolve to .9 in a Windows file
sharing context?

 

[Michael A. Covington]

Further info inserted below...

It's resolving to the Internet connection rather than the LAN connection.
Here's the whole picture (names changed of course):

server1.dept.school.edu resolves to the Internet connection of server1,
which I'll call 128.x.x.3.

server1 (as a Windows networking name on a VPN client) also resolves to
128.x.x.3

128.x.x.9 is the LAN connection (i.e., the second Ethernet card) of server1.

On a VPN client, "net view 128.x.x.9" works; "net view 128.x.x.3" and "net
view server1" do not.

I would like "server1" (without .dept.school.edu) to resolve to 128.x.x.9,
but "server1.dept.school.edu" to resolve to 128.x.x.3.

I should add that everything else on the LAN resolves correctly, e.g.,
server2, server3...

Is this a reasonable request? Or do I need to do some major rearranging of
names?

Would it be sufficient if I had them change the campus DNS tables so that

www.dept.school.edu is still 128.x.x.3, but
ais1.dept.school.edu becomes 128.x.x.9 ?

Would this make "ais1" (without suffixes) resolve to .9 in a Windows file
sharing context?

Or should I deploy an LMHOSTS on all the clients to tell them that server1
is 128.x.x.9?

ALSO, at this point I am motivated only by curiosity, since we have enough
functionality for our users. And if the way of getting into one of the
machines is slightly quirky, so be it; it probably gives us a tad more
security. Thanks for those who have responded!

 

[Bill Grant]

It's basically a DNS problem, and you might like to post it in the DNS
newsgroup. You might also like to look at KB 292822 about the problems with
DNS on a DC running RRAS.

 

[Michael A. Covington]

Thanks. The solution we've opted for is just to put a couple of entries in
everybody's HOSTS file. We can do this with a script that they run when
they set up the connection.