VPN clients cannot talk to each other?

[Mankyway]

I am struggling to find out why two VPN Clients cannot see each other either through Ping, trace, ftp etc
The VPN in question is on the main VLAN (100)and I am using a /22 subnet with the third octet being used to identify LAN users (192.168.100.x and VPN users(192.168.101.0)
I am using a Cisco 3000 VPN Concentrator.
From Client One (101.1) I can ping the gateways and all servers on .100.0, but cannot ping, trace etc to Client Two (101.2) and vice versa, from Client Two.

Is this a well known Gotcha or should I try to explain myself in more detail?

Thanks

 

[Noway2]

When you do a trace, how far does the connection get? To the gateway?

My initial reaction is that you need make sure that there isn't a firewall that is preventing traffic and then you need a means to provide NAT between the nets.

 

[Mankyway]

Thanks for the response,
As far as the trace, I only get as far as the Public IP address of the Concentrator.
I was pondering that as the client is on the "outside" interface and calling another client on the "outside" interface, whether this could be allowed,(My technical limitations will not permit me to ask why not? )
Regarding the NAT between Nets, There aren't two nets, the 192.168.100.0/22 will encompass the 192.168.101.0 (192.168.101.1 -192.168.101.100 range, which is in the address pool of the Concentrator).

Once again I appreciate your response.

 

[Noway2]

My skill level with VPN is intermediate, so hopefully an expert will jump in and assist.

My understanding is that the hosts are logically on the same network (ip/ mask) but as the data is routed over a different (public) segment(s) that at some level a translation must take place. I think this is where things are breaking down as it appears you can "see" the gateway devices, but not beyond. Basically, your system needs to know how to route the data to the VPN interface when appropriate versus the local LAN segment. To put it another way, if traffic is from 192.168.100.1 to 192.168.101.1, your setup needs a way to route this out the VPN interface rather than the LAN interface.

If I understand your situation correctly, I have the same problem with my VPN, using OpenVPN, and have been on and off attempting to get a solution, but haven't found one that is satisfactory.

I'm sorry that I can't be of more help. I think I understand what the problem is, but I don't know enough to tell you how to solve it.

 

[Mankyway]

I think we are on the same page, yes!
My thinking on the matter is, if the Concentrator doesn't know the route, it will send it to the Gateway of last resort, That Gateway can ping both clients, so perhaps it won't send a packet back throught the port from which it came(?), Just guessing.

Thanks for the input

 

[Noway2]

Your explanation sounds reasonable. It also gave me an idea. Can you add (static) routes to the concentrator and could you define a route such that if an attempt is made to access a remote (other VPN host) resource that it routes via the VPN interface?

Since they are on the same network segment, as long as you can get the traffic to the right segment, the appropriate host should respond.

 

[Noway2]

Don't know if this will help your situation or not, but as I am having a similar situation, I did some experimenting. I was able to get access to and from LAN resources via the VPN. In order to do this I had to do three things. Note, I use a linux box as the VPN gateway, so in implementation yours may be different, but the concepts may help.

On the gateway:
1 - I turned on ip forwarding.
2 - I added a NAT step where it translates traffic coming in on the VPN interface and forwards it to the eth0 port that ties to the LAN.
This established connectivity TO the lan, but not from it.

Then on the LAN resource:
I added a static route to the VPN subnet using the VPN PC as the gateway. ** your comment about wanting to route to the default gateway instead of the VPN was the key ** I did a traceroute from the LAN to the remote host and saw that it was routing to the default gateway, not the VPN.

In your case, your VPN and LAN have the same subnet, so it may be as simple as getting it to route to the proper interface.