|
|
On Fri, Oct 29, 2004 at 07:39:33PM -0600, James Yonan wrote:
> On Fri, 29 Oct 2004, James Yonan wrote:
>
> > On Fri, 29 Oct 2004, Matt Wilks wrote:
> >
> > > I am running OpenVPN in server mode and am trying to allow clients to
> > > receive a static IP address each time they connect. Using the server
> > > directive to set up the ip pool:
> > >
> > > server 192.168.2.128 255.255.255.128
> > >
> > > And then after that, the client-config-dir option to manually assign
> > > the IP address (which appears after the server option; I tried it before
> > > also with no success):
> > >
> > > client-config-dir /etc/openvpn/static
> > >
> > > In a correctly named file in that directory sits one option:
> > >
> > > ifconfig-push 192.168.2.137 192.168.2.138
> > >
> > > This almost works, but not quite. The client that is connecting
> > > receives the correct IP address (192.168.2.138), but the
> > > ifconfig_pool_remote_ip and ifconfig_pool_local_ip environment variables
> > > are set to the wrong addresses. From the log file (edited a bit):
> > >
> > > 'ifconfig_pool_remote_ip=192.168.2.134'
> > > 'ifconfig_pool_local_ip=192.168.2.133'
> > >
> > > Notice that this is the first /30 subnet that would have been handed out
> > > had the ifconfig-push directive not been given (which the man page says
> > > is supposed to override the ifconfig-pool option issued the server
> > > command). This handicaps my client-connect script as it relies on the
> > > remote_ip to do its processing. Strangely enough, when the client
> > > disconnects, OpenVPN gets the remote_ip and local_ip environment
> > > variables correct (from the log file, edited once again):
> > >
> > > 'ifconfig_pool_remote_ip=192.168.2.138'
> > > 'ifconfig_pool_local_ip=192.168.2.137'
> > >
> > > Thought I would bring this to your attention as it may be a bug.
> >
> > This behavior is by design.
> >
> > When the client-connect script is called, OpenVPN sets
> > ifconfig_pool_{local,remote}_ip with tentative pool addresses which the
> > script can CHOOSE to use. Remember that when OpenVPN calls the
> > client-connect script, it doesn't yet know whether the script will choose
> > to use the presented ifconfig_pool endpoints or whether it will select its
> > own by writing a custom "ifconfig-push" directive to the temporary
> > filename which is passed as an argument to the script.
> >
> > If the script doesn't write anything to the temporary file, OpenVPN then
> > scans the client-config-dir directory. This model says that if the
> > client-connect script generates a config, it has priority. Otherwise the
> > client-config-dir is scanned.
> >
> > Now, later, when the client-disconnect script is called, OpenVPN already
> > knows the endpoints which were defined by the ifconfig-push in the
> > client-config-dir, so it presents those as
> > ifconfig_pool_{local,remote}_ip.
> >
> > So the crux of the problem is that OpenVPN first calls the client-connect
> > script and only then reads the client-config-dir file if the
> > client-connect script didn't generate it's own custom config file.
> >
> > The problem is that your script is assuming the reverse -- that the
> > client-config-dir file will be processed first, and any ifconfig-push
> > directive found will be reflected in the ifconfig_pool_{local,remote}_ip
> > parms passed to the client-connect script.
> >
> > The problem with using this order of operations is that if the
> > client-config-dir file is read first, then the client-connect script
> > doesn't have an opportunity to generate its own set of config directives.
> >
> > It's an interesting conundrum and I can see why it might be useful to do
> > it either way.
>
> One thing I'd add is that the "learn-address" script callback is
> probably a better place to process the virtual address which was given to
> the client, because it is called after the client-connect script is run
> and the client-config-dir file is processed.
>
> Let me also add some documentation to clarify the client connect process:
>
> Order of operations on initial client connect.
> ----------------------------------------------
>
> Get tentative pool addresses, set ifconfig_pool vars. These addresses are
> tentative, i.e. they might be released if they are overridden with a
> client-specific ifconfig-push directive.
>
> Run client-connect script with temporary filename as argument.
>
> If client-connect script wrote config directives to temporary file,
> then:
> source temporary file,
> else
> if client-config-dir script exists, source it.
>
> If we sourced a file which contains an "ifconfig-push" directive,
> then:
> use the ifconfig-push addresses as the client tunnel endpoints
> and return the tentative pool addresses allocated earlier
> back to the pool,
> else
> use the ifconfig-pool addresses as the client tunnel endpoints.
>
> Call the learn-address script with the decided-upon client
> tunnel-endpoint. Call the learn address script separately with any extra
> client-side IP addresses or subnets as specified by any "iroute"
> directives.
>
> James
>
Many thanks for your response. Most helpful.
Matt.
--
Matthew Wilks
University of Toronto Computing and Networking Services
(416) 978-3328 matt@xxxxxxxxxxxxxxxxxxxxxxx
4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1
|