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

Re: [Openvpn-users] OpenVpn 2.0 RC2

  • Subject: Re: [Openvpn-users] OpenVpn 2.0 RC2
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Mon, 20 Dec 2004 15:41:05 -0700 (MST)

On Mon, 20 Dec 2004, Keith Beidelman wrote:

>   I have been doing some testing with OpenVPN 2.0 RC1 since last week.  I
> am new to OpenVPN.  I started out with 1.6, but quickly realized that the
> server enhancements in 2.0 were what I really wanted.
>     I am using TAP TCP.
>    1) There should be a difference between the subnet specified in the
> server statement, and the dynamic IP allocation range.  I wanted to setup a
> list of clients which should get static IP addresses, and let the server
> allocate one dynamically to anyone not on the list.  Both the static and
> dynamic IP's must be in the TAP subnet.  The server sees to want to allocate
> IP's over the entire range mentioned in the SERVER subnet, and I need a way
> to disallow a small range to be used for static IP's.  I thought the
> IFCONFIG-POOL keyword would do this, but I got a message that said it was
> not allowed with SERVER.  It appears that the server always allocates IP's
> from low numbers to high numbers, so for now, I put my static IP's at the
> high end (just before the broadcast address).  I also set a maximum clients
> to less that the number of IP's available before a collision.
>    I got the client-connect script to work to override the IP allocation in
> the special cases where I wanted static IP's.  But, at first, I ran into
> some problems with this:

All of this is possible.

See the man page entry for "server" -- it's just a macro.  You can
deconstruct it into its component directives and do what you'd like to 

Also see --client-config-dir and --ifconfig-push -- these will allow you
to give fixed IP addresses to selected clients.

2) It 
>took me the longest time to figure out how 
>to pass the IP back from
> the script to the server.  I did a "set > log" in the script, and realized
> that there was a strange filename attached to $1.  I also found
> documentation on TMP-DIR that gave a hint.  I finally inferred from all of
> this that I should write config commands to $1.  I think there were also
> hints in the log files.  But, in spite of all the documentation in the man
> page about the environment, it never mentioned that you could write a
> dynamic config script to $1.  I also think the commands which are accepted
> in the script, should be noted.

This is mentioned in the man page entry for --client-connect, though it 
could probably use some amplification.
> 3) Some of my connections are for OFFICE-OFFICE connections.  I have subnets
> to add to the routing table in both directions.  On the server side, I can
> use a PUSH ROUTE, this works great.  On the client side, I wanted to add a
> ROUTE to the client-connect script, but that is not allowed.  I finally just
> set up some static routes in the UP script for everyone, then allocated the
> OFFICE-OFFICE connections static IP's.

It's not clear to me why you can't use push "route ..." on the server side 
to do this.  The client-connect script is a server-side only script.  It 
is not used on the client side.

Are you saying you want clients to be able to push routes to the server
for further propagation to other clients?  This is not supported, mostly
for security reasons, and because it goes against the principle of 
centralized management that the 2.0 server mode tries to adhere to.

>  4)  The scheme I decided to use for allocating static IP's in the special
> cases was to put a DNS name of a host which maps to the static IP in the CN
> of the certificate.  The only problem I ran into with this was that a "PUSH
> IFCONFIG" keyword does not accept a DNS name, only a numeric IP.  So I had
> to write some special glue in the script to fetch the IP for the DNS name.
> It seems that the parser for IFCONFIG should accept DNS names just like
> REMOTE does.

That's something that could be patched fairly easily in the code.  You 
just need to OR in the GETADDR_RESOLVE flag before calling getaddr.

> 5) In the WIn32 version it would be nice if you could create your VPN config
> files in one folder, than allow a shortcut to the connection in the  Program
> Files\OpenVPN\config file.  You may want to setup connections which you
> don't want to auto start with the service.  I guess you could also have an
> AUTOSTART keyword in the config file instead.   But the point is that you
> won't want ALL your connections to AUTO Start.  In practice, what I did was
> to put all of my config files in \etc\vpn.  I then copied the ones I wanted
> to auto start to OpenVPN\CONFIG.  But a shortcut would be nicer than a copy.
>   6) what do you think of adding an option which tells the Win32 to launch a
> file browser dialog for picking the config file.  Perhaps you could also do
> this if you give the --CONFIG without a filename.  I do this in some of my
> WIn32 console applications.  I will attach some source code.  I may also try
> to hook it into the code myself.

Check out the OpenVPN GUI.

> I am a software engineer, who needed internet connectivity to my clients.
> Some of my clients are Unix/Linux based, and others are Windows based.
> IPSEC has too many problems with NAT and traversing a firewall.  Microsoft
> VPN is unreliable, and does not have enough configuration options to be
> flexible enough (for the routing and establishing static IP's for certain
> clients).  OpenVPN 2.0 seems to be the perfect answer for my quest to find a
> great VPN package for my business.  I also like having access to the source
> code,  so I can debug things in the event that something strange happens,
> but I have not had to do this yet.
> I set up some configuration files,. and sent them to my clients, along with
> install instructions.  It went allot smoother than talking someone through
> where to find and set the options in the Microsoft GUI.
> The overall package works great.

That's great to hear!


Openvpn-users mailing list