[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: Jamie Kirkpatrick <jkp@xxxxxxxxxxxxxxxxxxxx>
  • Date: Sun, 23 Jan 2005 18:47:30 +0000

Hmmm

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

jamie

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
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