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

Re: [Openvpn-users] Internal routing problem on V2 client-server install


  • Subject: Re: [Openvpn-users] Internal routing problem on V2 client-server install
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Sat, 22 Jan 2005 00:28:53 -0700 (MST)

On Fri, 21 Jan 2005, Jamie Kirkpatrick wrote:

> hi there
> 
> I am running openvpn 2.0pre6 on a router in server mode, and on two 
> separate remote clients.  I am using TAP to bridge the clients into the 
> host network.
> 
> The main network is 192.168.2.0.  I use a client connect script to 
> force each client to persistently pick up the same IP on each 
> connection and I am using certificate based authentication.  everything 
> is working just fine, in that the clients authenticate and connect just 
> fine and I can ping through the tunnels on either end.  The problem 
> comes when I am trying to reach the two clients from other boxes on the 
> host network.
> 
> I was finding it impossible to ping the second client and I couldn't 
> work out why.  Some investigation has turned up some very strange 
> results.  From the router (192.168.2.254) I could ping either client as 
> I mentioned but when I traceroute'd it showed some very very strange 
> results.
> 
> Tracerouting to 192.168.2.10 would go directly there, but tracerouting 
> to 192.168.2.11 would always route through 192.168.2.10!  This was 
> obviously the root of my problem in some way and so I did some further 
> investgation.  What I have found is that there is a direct correlation 
> between the contents of the internal routing table shown in my status 
> log (I have status logging enabled on the server) and the routing 
> issues i am seeing.  The client list in the status log shows both 
> clients, but the routing table only ever shows one entry - the client i 
> can directly route to.
> 
> I have managed to work out that the entries in the internal routing 
> table are created when the server executes a peice of code that 
> genertes an entry such as
> 
> Fri Jan 21 13:11:11 2005 us=549269 tom/217.42.40.148:50568 MULTI: 
> Learn: 74:61:70:00:00:00 -> tom/217.42.40.148:50568
> 
> in the main log files.  What is happening is that when I go to ping the 
> first client for the first time it learns about the route to reach it 
> (god knows why it doesnt make an entry upon connection in the first 
> place)

OpenVPN is acting as an ethernet bridge in this configuration.  Ethernet
bridges "learn" the network topology by observing ARP messages, so the
entry will not actually be added to the MAC routing table until OpenVPN
sees the first ARP message.

If you ran OpenVPN in tun mode (i.e. routing mode), then the client 
virtual address would be added immediately upon client authentication.  In 
routed mode, no dynamic learning occurs.

> and adds it to the internal routing table.  Then when I go to 
> ping the second client it uses the intial route it has stored in its 
> internal routing table -obviously the wrong thing to do.  If i 
> persistently traceroute to the second client, what actually happens is 
> that eventually learns about the real route, BUT instead of adding it 
> to the list in it's internal routing table it wipes the first and 
> replaces it with the second!  The learning process can be proved by 
> rechecking the main log file where a new MULTI: Learn entry will be 
> present.  After that has happened, I can traceroute to the second 
> clientfine, but the problem has now been reversed and if i try a 
> traceroute to the first client it routes through the second client!

Are you sure you're not making the common mistake of reusing the same
certificate/key or common name among different clients without adding the
"duplicate-cn" config file directive? (see FAQ)

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users