Nonsense! You cannot talk to your VPN children? 1

[IfAtFirst]

It's true. When doing router-to-router VPNs, like Linksys (BEF)SX41s and VP41s, you cannot talk to someone with the same DNA (IP address on the same segment) through a tunnel.

You must use distinctly different segments at each end, or a packet in the tunnel doesn't know which way to turn.

Yet... routers or VPN servers using DHCP to dispense numbers for road-warrior clients must be giving out numbers in the same family (same segment).

Can someone confirm this, or steer me straight?

It doesn't seem scalable that road warriors wanting to reach a 192.168.1.0 segment must be numbered 192.168.2.something.

When you have a lot of scattered offices, you can go nuts looking for "other" segments for the road warriors to use.

It seems to me an issue of more sophisticated routing on the target LANs.

Are there routers that tolerate remote clients having real numbers or virtual addresses on the same segment?

 

[PaulGillespie]

You are correct! not sure what you mean in your last question though.

 

[themut]

You cannot communicate through a tunnel betweeen two sites with the same IP addressing scheme unles you NAT the traffic at both ends. The problem is not the VPN but the machines on the same networks, let's assume you have 1.1.1.1 on one side of the tunnel and 1.1.1.2 on the outher side of the tunnel... now when 1.1.1.1 sends a packet destined to 1.1.1.2 it assumes both are on the same network so it doesn't use the gateway, therefore the packet is not sent through the tunnel but instead it uses the MAC address to try to deliver the packet on the same "side" of the tunnel.

To oevercome this issue you have to NAT the traffic at both ends, so let's say you nat oned side to 2.2.2.0 and the other end to 3.3.3.0. Now 1.1.1.1 will send a packet to 3.3.3.2 and host 1.1.1.2 on the other end will see this packet coming from 2.2.2.1. Since now they appear comming from different networks both ends will use the default gateway, thus resolving the problem. That's my two cents...

 

[lgarner]

For your last question, you can assign an address to road warriors out of a pool of internal addresses. This is common. The user's *real* address must still be reachable by the vpn router and must be part of an internal network.

 

[IfAtFirst]

Thank you (so far) to Paul, themut, and lgarner (and to wa1dar who answered nearly the same question in the Remote Access forum).

My further discoveries have been that I can put the target on a subsegment of 192.168.1.0/24 - say 192.168.1.0/27, and I can get the remote client with a virtual address 192.168.114 to work.

Sentinel lets you specify a mask for the virtual address - putting it on a defacto virtual subsegment. Both of these masks worked, when connecting to the Linky:

255.255.255.224 and
255.255.255.255

If I broadened the definition of the tunnel's target subsegment to 192.168.1.0/24, the tunnel worked when the mask for the remote VA was 255.255.255.255.

But I could only connect to machines whose adapters thought they were sequestered on a distinct subsegment. That meant leaving my target's actual network adapter as 192.168.1.25/27.

When I changed the mask of the target box (..25, which hosts a Webserver) to 255.255.255.0, all bets were off (except for being able to ping the LAN gateway on the Linky.

My conclusion, from advice (thank you) and experience (ouch) is that the target hosts should be numbered so they can be confined to a subsegment, so my road warriors can be on distinctly different subsegments.

I'm assuming that's what lgarner meant by reference to remote users drawing on a "pool of internal addresses." Addresses in this pool would have to fall into a different subsegment, or my experience is that they can't reach their targets.

Reminds me of playing "battleships."

 

[lgarner]

Actually, the pool of addresses can work either way. You can set aside a range of unused addresses on your internal network, or create a new segment. It depends on the features of your VPN gateway. The key, though, is that the client's actual address must be different from any of your networks that it needs to reach.

I just re-read my post and see that an important word was missed. The last part should read "...and must *not* be part of an internal network." That's what I get for trying to think and type at the same time.

 

[IfAtFirst]

I seem to have spoken to soon of my presumption of limted success with using a software client to talk to a Linksys router - putting each on distinct LAN segments.

A tabletop setup using 2 (BEF)SX41s worked as I described.

In the real world, I placed VP41s at my target sites. I liked their ability to let me configure more tunnel options. I also find them nearly free from getting hung.

The VP41 on my target LAN lets me connect with either (SSH-abandoned) Sentinel, or Safenet SoftRemote. (Safenet bought the related VPN client assets from SSH.) I have these babies mounted on 2 different boxes, behind the same gateway - where I sit.

But once I connect, using either, I can't do further business on the target LAN.

Linky logs say the connection was created, so it's frustrating.

 

[IfAtFirst]

Moving towards a solution using SSH's last gasp guidance: 'Don't confuse me with virtual adapter address and gateway info,' says the VP41, 'Just use ANY / ANY.'

This helped. I connected and did well with the VP41s in another tabletop setup.

With Sentinel (but not with SoftRemote), I can specify subnets of Class C addresses - thus oberving the separation of powers demanded in routing.

This allows 192.168.4.114 (remote, on Sentinel) to talk to 192.168.4.41 behind a Linky, as long as the mask for each is 255.255.255.192 - putting them on different subnets.