[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: Sun, 23 Jan 2005 11:42:31 -0700 (MST)

On Sat, 22 Jan 2005, Jamie Kirkpatrick wrote:

> 
> On 22 Jan 2005, at 07:28, James Yonan wrote:
> 
> > 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.
> 
> OK - that makes sense. :)
> 
> >
> >> 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)
> 
> Nope.  Definitely not using the same certs / keys / CN's.  I generated 
> a separate pair for each client and made sure they have different CN's 
> so that I can push specific IP's to each client: that is currently 
> working.  I addded the duplicate-cn directive to the server and 
> restarted just to check that there was nothing wrong with the data in 
> the keys / certs and it made no difference.
> 
> Any other suggestions? Really hope you can help me nail this!!!

The only cases where OpenVPN should replace an item in its internal
routing table with a different entry is when another client connects with
the same common name and --duplicate-cn is not specified or when the same
MAC or IP address is relearned in association with a different client.

James


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