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.
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:
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 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.
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
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
I mentioned but when I traceroute'd it showed some very very strange
Tracerouting to 192.168.2.10 would go directly there, but
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
investgation. What I have found is that there is a direct
between the contents of the internal routing table shown in my
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
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/184.108.40.206:50568 MULTI:
Learn: 74:61:70:00:00:00 -> tom/220.127.116.11:50568
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
(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
entry will not actually be added to the MAC routing table until
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
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
that eventually learns about the real route, BUT instead of adding
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
"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
the same common name and --duplicate-cn is not specified or when the
MAC or IP address is relearned in association with a different client.