[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Possible routing problem


  • Subject: Re: [Openvpn-users] Possible routing problem
  • From: "Daniel L. Miller" <dmiller@xxxxxxxxx>
  • Date: Tue, 28 Aug 2007 12:27:59 -0700

I should follow this up by saying I do NOT want the remote clients to 
see each other - I just want to be able to access all those remote 
clients from my own LAN.

Daniel L. Miller wrote:
> Does "client-to-client" need to be enabled?  Or do I need to configure 
> some server-side routing or forwarding rules?
>
> Daniel L. Miller wrote:
>   
>> 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
>>>       
______________________
OpenVPN mailing lists
https://lists.sourceforge.net/lists/listinfo/openvpn-users