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

RE: [Openvpn-users] Addressing weirdness in routing mode: Solved!


  • Subject: RE: [Openvpn-users] Addressing weirdness in routing mode: Solved!
  • From: "Wright, Paul" <pwright@xxxxxxxxxxxxxxxxx>
  • Date: Thu, 13 Apr 2006 02:32:43 -0700

Title: RE: [Openvpn-users] Addressing weirdness in routing mode: Solved!

>I would suggest _not_ doing this, the routing applied with the server
>directive is the canonical behaviour of OpenVPN. Look at the server
>directive in the manual pages.


Erich -

I appreciate your suggestion.  I did review the man page on the server configuration, with particular attention to how it expands.  According to this, it will do this:

mode server
tls-server

and if a tunnel, it will

ifconfig 10.8.0.1 10.8.0.2
ifconfig-pool 10.8.0.4 10.8.0.251
route 10.8.0.0 255.255.255.0
push "route 10.8.0.1"

But in my case, it gave itself the x.x.x.1 and gave the other end of the tunnel
x.x.x.6 rather than x.x.x.2 and the default gateway on the client end pointed to x.x.x.5
rather than x.x.x.1.

Is there another directive that interacts with the server directive to cause
the behavior I've described?  It seems that if I use the server directive,
I will have to do something with a script to get the routing set up properly,
based on what I have observed.

On the LEAF Bering end, I used the openvpnz.lrp package so I don't know exactly what version that is, but I used v2.0.5 on the Centos end.  Is is possible that this observed behavior is the result of a version mis-match?  If so, I might have to stick with my non-canonical workaround until I can make a new lrp package.

Regards,

paul