2 sites with same subnet causes routing problem for VPN TS connection ?

  • Thread starter Thread starter scott
  • Start date Start date
S

scott

Hi,

I have a problem connecting to terminal server on a remote site over vpn as
they use the same subnet 192.168.1.#. i.e vpn connection ok but cant find
terminal server on 192.168.1.1 on site 2 from clinet at site1.

------------------------------------------------------------------
terminal server
192.168.1.1
|
vpn services site 2
|
net
|
router site 1
192.168.1.1
|
192.168.1.2
client
------------------------------------------------------------------

I thought i could get around this by creating another subnet at site1 i.e
10.10.10.# using a router (one port has 192.168.1.200 other port had
10.10.10.1) and adding the client to the 10.10.10.# subnet.

If i do this and when a vpn connection is established creating a tunnel,
will my clinet with the IP 10.10.10.10 route to site 2 to find 192.168.1.1 ?

i.e so new network will look like this:

------------------------------------------------------------------
terminal server
192.168.1.1
|
vpn services site 2
|
net
|
router site 1
192.168.1.1
|
192.168.1.200
new router
10.10.10.1
|
10.10.10.10
client
------------------------------------------------------------------

So clinet creates tunnel to sites 2, and finds site 2's subnet 192.168.1.#
instead of site 1s.

Will this work ?

Is there another way to deal with this ? (apart from changing the subnet at
site one from 192.168.1.# to somthing else).

Thanks
Scott
 
One network will have to be re-addressed. It doesn't matter how may "hoops"
you jump through along the way, ...in the IP Packet headers the "destination
address" you are contacting would still be from the same subnet as the
source address and would fail or go to the wrong machine.

We have over 20 sites spread across the US and Puerto Rico all connected by
VPN, and we *always* have to verify what addresses the other sites are using
before we add a new address range, and records of it are kept at each site.

If connectivity is limited to one Host at each location then a NAT Device
could be put at each end in the circuit and a Static NAT or One-to-One NAT
could be used to overcome this,...but that is only practical with one Host
(maybe 2 or 3) at each end.
 
hi,

thanks for the reply Phil, thats saved my time trying. I knew there had to
be a flaw in my theory somewhere.....

thanks again
scott
 
Scott,

You do not HAVE to re-address either network though that is certainly the
least technical way to do that. This is a common problem with VPNs and
Cisco has an article that covers how to manage this with either a router or
PIX as the tunnel endpoint. I can't find the article just now, but I know
its there.

I would bet that this was relying on NAT rules to address (sic) this, but
the catch is to know when to route across the tunnel. You could certainly
give access through static NATs and static routes, but not on the fly --
just to things like server resources.
 
here is another idea.

i have a dmz at site one one a different subnet

___________________________________________________________
terminal services
192.168.1.1
|
192.168.1.2
router site2
|
net
|
router1 site1 _ _ _ _ _ 192.168.2.# clinet PC
192.168.2.#
|
|
192.168.2.#
router 2 site1
192.168.1.#
|
LAN
___________________________________________________________

I could hang a client in the 192.168.2.# subnet using router 1 as gateway as
it would never know about router 2 at site 1 and the 192.168.1.# subnet at
the other side.
It would do the job in the short term.


ANOTHER QUESTION
In addition i attempted to setup a static route on router2 that was defined
as:
192.168.1.1 using gateway 192.168.2.1

This totally shafted the router and i couldnt connect to it from 192.168.1.#
machines.. Had to reset it and build rules/nat again. Why did this happen ?

Cheers
Scott
 
I can't follow what you are describing well enought to say what happened.
But I can say catagorically that you are waisting your time. You are not
stumbling on anything unique that isn't already known about. All that
matters (when not using NAT) are the two end points,...if the are the same
subnet, and possibly enve the same IP# then it will fail,...plain and
simple. It does not matter how many "headstands and cartwheels" you do in
between the two points. TCP/IP routing works on the priciple is works on and
behaves the way it behaves, you aren't going to change that.

Cisco does have a proprietary nat based system of overcomming this as Ryan
mentioned. I have no exact details on it, but it is probably the only way
it would work. However keep in mind that Cisco's solutions are very
proprietary and usually don't work when "blended" with other methods and
implementations from other products,...consider yourself "warned".
 
Back
Top