|
|
OK - I initially didn't think it would matter, since the server can communicate with the client. I'm trying to compile that information now. I did notice that on the workstation not working, there is both the 10.2.1.0 VPN, and a 10.4.something network (which is that workstation's default gateway). Would there be a conflict there? David Balazic wrote: > A works, B don't. Off course its routing table matters. > Also the routing table of the other end (the server). > And the routing of any in-between routers, for that matter. > > So, at least : > - routing on B > - routing on server > > Without this info, we can only guess what is wrong. > > David > > ------------------------------------------------------------------------ > *From:* openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx on behalf of > Daniel L. Miller > > I only ran the "route add 10.2.1.0" on client A - but I wouldn't expect > that to matter. Client "B" is on a totally different network, connected > to mine via Internet and OpenVPN. > > David Balazic wrote: > > Is there any difference between the routing tables on client A and > > client B ? > > > > David > > > > ------------------------------------------------------------------------ > > *From:* openvpn-users-bounces@xxxxxxxxxxxxxxxxxxxxx on behalf of > > Daniel L. Miller > > *Sent:* Tue 28-Aug-07 01:20 > > *To:* openvpn-users@xxxxxxxxxxxxxxxxxxxxx > > *Subject:* [Openvpn-users] Possible routing problem > > > > Hi! > > > > I'm trying to reach a vpn client from an internal workstation. The > setup: > > > > Linux OpenVPN server, LAN address 192.168.0.72, routed TUN address > > 10.2.1.1 > > Windows XP OpenVPN client "B", VPN address 10.2.1.14 > > Windows XP OpenVPN client "A", VPN address 10.2.1.6 > > Windows XP LAN Workstation (well, technically virtual workstation on > > OpenVPN server), 192.168.0.55 > > > > From the OpenVPN server, I can ping any of the above. Some routing and > > address output: > > 10.2.1.2 dev tun0 proto kernel scope link src 10.2.1.1 > > 192.168.20.0/24 dev vmnet8 proto kernel scope link src 192.168.20.1 > > 10.2.1.0/24 via 10.2.1.2 dev tun0 > > 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.71 > > 192.168.0.0/24 dev br1 proto kernel scope link src 192.168.0.72 > > 192.168.30.0/24 dev vmnet1 proto kernel scope link src 192.168.30.1 > > default via 192.168.0.1 dev eth0 > > > > 8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,10000> mtu 1500 qdisc > > pfifo_fast qlen 100 > > link/[65534] > > inet 10.2.1.1 peer 10.2.1.2/32 scope global tun0 > > > > BTW - I don't know what that "peer 10.2.1.2" means - I can't ping it > > from anywhere. > > > > On the virtual workstation, I have executed some routing commands, like, > > "route add 10.2.1.1 mask 255.255.255.255 192.168.0.72". The routing > > table now shows: > > Active Routes: > > Network Destination Netmask Gateway Interface > > Metric > > 0.0.0.0 0.0.0.0 > > 192.168.0.71 192.168.0.55 10 > > 10.2.1.0 255.255.255.0 192.168.0.72 > > 192.168.0.55 1 > > 10.2.1.1 255.255.255.255 192.168.0.72 > > 192.168.0.55 1 > > 127.0.0.0 255.0.0.0 127.0.0.1 > > 127.0.0.1 1 > > 192.168.0.0 255.255.255.0 192.168.0.55 > > 192.168.0.55 10 > > 192.168.0.55 255.255.255.255 127.0.0.1 > > 127.0.0.1 10 > > 192.168.0.255 255.255.255.255 192.168.0.55 > > 192.168.0.55 10 > > 224.0.0.0 240.0.0.0 > > 192.168.0.55 192.168.0.55 10 > > 255.255.255.255 255.255.255.255 192.168.0.55 > > 192.168.0.55 1 > > Default Gateway: 192.168.0.71 > > > > From this workstation, I can ping 10.2.1.1 (the server) and 10.2.1.6 > > (workstation "A"). However, I cannot ping workstation "B". But I CAN > > ping workstation "B" from the server. From this I deduce workstation > > "B" is configured reasonably well, and there's no firewall or routing > > issues on that workstation (or the server couldn't reach it). But why > > can I not ping that workstation from another workstation - when I can do > > so for others? > > -- > > Daniel > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ > > Openvpn-users mailing list > > Openvpn-users@xxxxxxxxxxxxxxxxxxxxx > > https://lists.sourceforge.net/lists/listinfo/openvpn-users > > > > > -- > Daniel L. Miller, VP - Engineering > AM Fire & Electronic Services, Inc. [AMFES] > dmiller@xxxxxxxxx 702-312-5276 > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Openvpn-users mailing list > Openvpn-users@xxxxxxxxxxxxxxxxxxxxx > https://lists.sourceforge.net/lists/listinfo/openvpn-users > ______________________ OpenVPN mailing lists https://lists.sourceforge.net/lists/listinfo/openvpn-users |