[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
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: Jamie Kirkpatrick <jkp@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sun, 23 Jan 2005 18:47:30 +0000


well - neither of those were true afaik. I have now switched to a tun setup and all is working well - just wanted to get the darn thing to do what it should! anyway...its an excellent bit of software you have written - many thanks.

if i find tun mode too limiting ill switch back and try troubleshooting again, but for now i have something that should do what i want.

many thanks


On 23 Jan 2005, at 18:42, James Yonan wrote:

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
host network.

The main network is  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.
is working just fine, in that the clients authenticate and connect
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
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 ( I could ping either client
I mentioned but when I traceroute'd it showed some very very strange

Tracerouting to would go directly there, but tracerouting
to would always route through! 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
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/ MULTI:
Learn: 74:61:70:00:00:00 -> tom/

in the main log files. What is happening is that when I go to ping
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

OpenVPN is acting as an ethernet bridge in this configuration.
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.
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.