Can't ping/connect to network share from VPN tunnel

[aks]

Clarity on the diagram please:

1) Is the Server icon the CentOS server?
2) Are the various Workstation icons just Windows workstations?
3) Is Router actually routers (of what type?), or are the the Windows machines that provide the VPN?

Also, is what I said in my previous post correct (apart from the network diagram)? What VPN are you doing (e.g.: IPSec/SSL)? Are you using IKE?

[jsav]

Server = CentOS
workstations are windows xp/7
both routers are linksys LTR214
routers are providing vpn tunnel with IKE

thanks

[jsav]

forgot to add it is a IPSec tunnel.

[jsav]

some more information.

centos server has an ip of 192.168.1.32. i can ping any address 192.168.1.* and 192.168.2.*. 192.168.1* can ping 192.168.1.32 but 192.168.2.* can not ping 192.168.1.32

[aks]

So everything is fine from the left hand side of your diagram. The problem is from the right hand side of your diagram, trying to reach the left hand side of your diagram (where left is the left side of the WAN and right is the right side of the WAN). For connectivity across the WAN you have an IKE VPN that is up and seems to be running okay.
Further, the CentOS machine (server in the diagram) can ping any node on both the left and the right hand sides (when firewalls are off - just allow icmp ping though the firewalls and switch the firewalls on). The problem is the Windows machines on the right hand side can not ping the CentOS machine on the left hand side, but can ping Windows machines on the left hand side.
Is that about right?

I'd suggest using traceroute (or something similar) to see where the packets get lost. Is the problem with the first router, or the second router or final delivery?

[jsav]

everything you wrote about diagram is correct.


tracert from centos to 192.168.2.105 (wondows machine)

[root@new-host ~]# ping 192.168.2.105
PING 192.168.2.105 (192.168.2.105) 56(84) bytes of data.
64 bytes from 192.168.2.105: icmp_seq=6 ttl=126 time=25.0 ms
64 bytes from 192.168.2.105: icmp_seq=7 ttl=126 time=23.8 ms
64 bytes from 192.168.2.105: icmp_seq=8 ttl=126 time=22.2 ms
64 bytes from 192.168.2.105: icmp_seq=9 ttl=126 time=22.4 ms
64 bytes from 192.168.2.105: icmp_seq=10 ttl=126 time=23.2 ms
^C
--- 192.168.2.105 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 9005ms
rtt min/avg/max/mdev = 22.282/23.359/25.033/1.017 ms
[root@new-host ~]# traceroute 192.168.2.105
traceroute to 192.168.2.105 (192.168.2.105), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 2.833 ms 2.766 ms 2.719 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * 192.168.2.105 (192.168.2.105) 23.264 ms 28.376 ms


====================================================
ping and tracert from windows machine (jeff=192.168.2.105) to centos (192.168.1.32) and another windows machine (192.168.1.103)

C:\Users\jeff>ping 192.168.1.103

Pinging 192.168.1.103 with 32 bytes of data:
Reply from 192.168.1.103: bytes=32 time=22ms TTL=126
Reply from 192.168.1.103: bytes=32 time=23ms TTL=126
Reply from 192.168.1.103: bytes=32 time=22ms TTL=126
Reply from 192.168.1.103: bytes=32 time=24ms TTL=126

Ping statistics for 192.168.1.103:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 24ms, Average = 22ms

C:\Users\jeff>tracert 192.168.1.103

Tracing route to EMB2 [192.168.1.103]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.2.1
2 * * * Request timed out.
3 23 ms 29 ms 25 ms EMB2 [192.168.1.103]

Trace complete.

C:\Users\jeff>ping 192.168.1.32

Pinging 192.168.1.32 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.32:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\jeff>tracert 192.168.1.32

Tracing route to 192.168.1.32 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.2.1
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.

C:\Users\jeff>

[aks]

[root@new-host ~]# ping 192.168.2.105
PING 192.168.2.105 (192.168.2.105) 56(84) bytes of data.
64 bytes from 192.168.2.105: icmp_seq=6 ttl=126 time=25.0 ms
64 bytes from 192.168.2.105: icmp_seq=7 ttl=126 time=23.8 ms
64 bytes from 192.168.2.105: icmp_seq=8 ttl=126 time=22.2 ms
64 bytes from 192.168.2.105: icmp_seq=9 ttl=126 time=22.4 ms
64 bytes from 192.168.2.105: icmp_seq=10 ttl=126 time=23.2 ms
^C
--- 192.168.2.105 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 9005ms
rtt min/avg/max/mdev = 22.282/23.359/25.033/1.017 ms

Hmm, first five packets lost.

[root@new-host ~]# traceroute 192.168.2.105
traceroute to 192.168.2.105 (192.168.2.105), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 2.833 ms 2.766 ms 2.719 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * 192.168.2.105 (192.168.2.105) 23.264 ms 28.376 ms

Okay we're good now, I guess the forwarding tables are populated (possibly because of the ping). That tends to suggest a network device issue (like a switch or a router).
The bad news is that you've got issues from left to right anyway (lost packets are not a good thing).

The hard part now is where are the left to right packets lost? Capture at the source (CentOS) and see if they all make it out the interface. Then capture at the left hand router to see if they all get there. Then capture at the right hand router to see if they all get there. Finally capture at the destination to see if they all get there. Where they don't get to is probably the source of the problem.

The same applies right to left. I would urge you to start left to right, as I have a hunch that some configuration error on the right hand router is responsible. But there again, hunches can be wrong....

[jsav]

i have solution:

needed to add a new route to my centos server:
route add -net 192.168.2.0/24 gw 192.168.1.1

thanks for your help