Problem with Server on a different subnet via VPN

[Kaido]

Solved!!


Cliff's at the bottom

I recently set up a VPN for my company using 2 Linksys RV082 VPN routers. I created a tunnel between the two routers; the primary site's internal IP is 192.168.253.x and the secondary site's internal IP is 192.168.11.x. Everything is peachy except for one thing: we can't connect to one of our databases servers. This particular database server is very old; we use terminal emulation software to log in to it. Basically you set the IP of the database server in the client app and then you can login to the server.

The problem is that VPN users cannot "see" that particular database server. VPN users can ping the router (192.168.253.1) as well as the Windows server (192.168.253.2), but not the old database server (192.168.253.3). We have complete access to the Active Directory setup on the Windows server, to our workgroup folders, even to the printers - just not the old database server. We tried changing an IP on one of the primary site's computers to the secondary site's IP (from like 192.168.253.100 to 192.168.11.4) and it wouldn't allow it access either, which says that the database server doesn't allow connections outside it's own IP segment.

My problem is this: the router's tunneling system requires the second site's internal IP to be on a different segment than the primary site's internal IP. However, if you are not on the primary site's internal IP segment, you cannot access one of the databases. This means that if you use the VPN you cannot access the old database server. How do I get around this? I can't change a VPN's IP segment to be the same as the primary site due to the software restrictions. When I ping the old database's server IP, I get a "Request timed out", but if I do it on any other computer on the network I get a response.

Cliff's:
1. Old database won't talk to computers outside it's IP segment
2. VPN requires VPN machines to be on a different IP segment
3. How to fix?

 

[spidey07]

the problem server most likely has a bad mask or incorrect/non-existant default gateway.

 

[nweaver]

indeed, this appears to be a Layer 3 issue...

when you say you cannot ping the database, I assumed database server. This tells me it's L3, you cannot route packets to or from that machine. Check his gateway, mask, and other settings to verify. What OS does this database run on?

 

[Kaido]

Originally posted by: nweaver
indeed, this appears to be a Layer 3 issue...

when you say you cannot ping the database, I assumed database server. This tells me it's L3, you cannot route packets to or from that machine. Check his gateway, mask, and other settings to verify. What OS does this database run on?

Yes, I meant database server. The machine runs on MPE off an HP 3000 (think 30 years ago); we use a terminal emulation system to log into it. We have a specialist who supports it, so I'll check in with him to see if he can walk us through changing the network settings.

 

[Kaido]

Originally posted by: spidey07
the problem server most likely has a bad mask or incorrect/non-existant default gateway.

So if a machine on a network has a valid static IP, but has a bad mask or bad gateway numbers, it won't talk to machines outside it's subnet?

 

[spidey07]

Originally posted by: Kaido

Originally posted by: spidey07
the problem server most likely has a bad mask or incorrect/non-existant default gateway.

So if a machine on a network has a valid static IP, but has a bad mask or bad gateway numbers, it won't talk to machines outside it's subnet?

That's exactly what it will do. A bad mask means the host doesn't properly know when to send to DGW. A missing or bad DGW means it sends it to the wrong L2 address of the router.

That's what a router does - it routes. Machines send frames (not packets) to the router, the router then devilvers it to it's next hop and so on until it reaches it's destination. Google around a bit for a "post office" analogy, it's a very fitting way to describe routing.

A host will send any an all frames/packets that are not "on the wire", meaning subnet, to their default gateway if no other routes are configured on the host. An inability to ping a machine is an L3 operation and that's where you should look.

 

[Kaido]

Originally posted by: spidey07

Originally posted by: Kaido

Originally posted by: spidey07
the problem server most likely has a bad mask or incorrect/non-existant default gateway.

So if a machine on a network has a valid static IP, but has a bad mask or bad gateway numbers, it won't talk to machines outside it's subnet?

That's exactly what it will do. A bad mask means the host doesn't properly know when to send to DGW. A missing or bad DGW means it sends it to the wrong L2 address of the router.

That's what a router does - it routes. Machines send frames (not packets) to the router, the router then devilvers it to it's next hop and so on until it reaches it's destination. Google around a bit for a "post office" analogy, it's a very fitting way to describe routing.

A host will send any an all frames/packets that are not "on the wire", meaning subnet, to their default gateway if no other routes are configured on the host. An inability to ping a machine is an L3 operation and that's where you should look.

Wonderful, thank you for the advice! I am going to contact our database guy tomorrow to see what we can do about it.

 

[RebateMonger]

n.m.

 

[spidey07]

Originally posted by: RebateMonger
n.m.

spill it.

You've been a big contributor to these forums. spill it.

 

[Kaido]

Just an update, the default gateway was incorrect. Thanks for the help! We ended up contacting the guy who handles managing our old server and were able to get it fixed pretty easily.