|
|
It appears, once again, that I was wrong. At least, I cannot
reproduce what I described, either. Both the LAN and the endpoint
seem to start working at the same time. I think what happened was
that it was remembering wrong settings (through persist tun, probably)
from where I had forgotten to include an iroute file.
However, it is still the case that restarting the client or the server
results in a significant delay before a connection can be
reestablished. I tried removing the "persist" commands and it
appeared to make no difference. Shouldn't it reread the ccd files
immediately when the client reconnects? I understand now why
restarting the server causes this problem, but why does restarting the
client cause a delay as well?
Regarding iroutes, it would be nice if an iroute command implied a
top-level "route command", as I can't see why you'd ever want an iroute
command without the corresponding route command. This would also
keep the main file cleaner and not require restarts when new CCD files
were added. It also makes CCD files portable from one VPN to
another. If this were a security risk, you might have a
--allow-ccd-routes flag to enable it or something.
Thanks again for your help.
-Dan
On 5/4/05, James Yonan <jim@xxxxxxxxx> wrote:
On Wed, 4 May 2005, Dan Hulme wrote:
> It appears that you're right, that eventually the iroutes are reestablished.
> But I've noticed that even if I restart the server, then the client, it
> often takes a while for the iroutes to be established.
I.e., I can ping from
> 192.168.1.1 <http://192.168.1.1>, but not from
> 192.168.1.2<
http://192.168.1.2>,3,4,
> etc. on my LAN. Later these computers can ping. I'm not sure exactly what's
> going on, but it definitely takes longer before LAN clients can ping then
> for just the tunnel endpoint to ping. I can't see how the timeout would
> apply in this case, if I have just restarted the server, then the client.
I can't reproduce this behavior, as you describe.
I ran a test in client/server mode, where the client routes a local subnet
through the VPN, and the server accepts this subnet via
"client-config-dir" and "iroute". I brought the server down and restarted
it, while the client remained connected. The client VPN went down for 120
seconds as it waited to timeout on the server connection (the 120 seconds
is controlled via the second parameter to the keepalive directive on the
server). During this time, I was pinging the server endpoint from two
separate machines on the client side, one from the OpenVPN client machine
itself, and another from the client's local subnet (via iroute). The
pings halted during this 120 second interval. When the connection came
back up, both pings resumed at exactly the same time.
I think it's important to figure out why, in your case, the packets coming
from machines in the iroute subnet are dropped for a certain length of
time after the client machine itself connects to the VPN. Perhaps a
tcpdump/ethereal scan would shed some light on this.
Also: there's currently a wish list item to do an explicit server ->
client exit notification on server exit in UDP mode. This would prompt
the clients to reconnect immediately rather than wait to be triggered by
the "keepalive" timeout.
James
> Previously I had been using UDP endpoints, so it wasn't really a
> server/client model. But back then, I could just restart both endpoints and
> my LANs could ping each other immediately. Is there a way to still achieve
> this? As long as it comes up eventually (read: few minutes), though, it's
> not a big deal, except for testing purposes, because the server almost never
> restarts the VPN.
When using 1.x, all routes are static, so you don't really have this
issue. Because the client/server model in 2.0 is dynamic, it is necessary
for internal OpenVPN routes to be dynamically added and removed as clients
connect and disconnect.
> Thanks,
>
> -Dan
>
> On 5/4/05, James Yonan <jim@xxxxxxxxx> wrote:
> >
> > On Tue, 3 May 2005, Dan Hulme wrote:
> >
> > > --I apologize if this message is repeated; Gmail seems to be having
> > trouble hitting this list.
> > >
> > > I recently switched a VPN server which had multiple tunnels to a single
> > tunnel using OpenVPN 2.0.
> > > First off I would like to say that the new design fixes nearly
> > everything I wished was in 1.5/1.6,
> > > so I am very impressed. I have been able to replace all tunnels with a
> > single tunnel, and single
> > > client-configurations are very easy and work correctly. So, thanks for
> > all your hard work, James.
> > >
> > > Previously, on my multiple tunnel interface, I had some tunnels which
> > connected two LANs. I have
> > > reimplemented these using
2.0, client-config-dir, and iroute. This
> > works, but has a major caveat.
> > > It seems if the server VPN reboots, the iroutes from the CCDs get lost.
> > Apparently, the server
> > > VPN loads these iroutes when the client connects. So, if the client is
> > already connected (i.e.,
> > > it did not reboot when the server did), the server never receives a
> > signal to load the CCD the
> > > second time, and internal LAN machines on the client side are not
> > connected to the internal LAN on
> > > the server side.
> > >
> > > This is very frustrating as it requires a client reboot if the server
> > ever reboots. With multiple
> > > LAN endpoints, a single reboot requires multiple remote reboots.
> > >
> > > Am I doing something wrong, or is this the current behavior of OpenVPN?
> > Perhaps on restart
> > > OpenVPN should reload CCD conf files if the client is still connected
> > (does it know?).
> >
> > I'm not sure that I follow this. If the server VPN reboots, or if the
> > OpenVPN server process is restarted, the server will start off with a
> > blank slate and no client connections. The previously connected clients
> > will individually time out based on the pushed "keepalive" setting,
> > prompting them to attempt reconnection and a full TLS renegotiation with
> > the server. This renegotiation will cause the "client-config-dir" files
> > to be re-read and iroutes to be added to OpenVPN's internal routing table.
> >
> > James
> >
> >
> > -------------------------------------------------------
> > This SF.Net <http://SF.Net> email is sponsored by: NEC IT Guy Games.
> > Get your fingers limbered up and give it your best shot. 4 great events, 4
> > opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> > win an NEC 61 plasma display. Visit
http://www.necitguy.com/?r=20
> > _______________________________________________
> > Openvpn-devel mailing list
> >
Openvpn-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >
>
Warning: require_once(../../../archive_common.php) [function.require-once]: failed to open stream: No such file or directory in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2005-05/msg00042.html on line 223
Fatal error: require_once() [function.require]: Failed opening required '../../../archive_common.php' (include_path='/usr/local/lib/php') in /home/openvpn/domains/openvpn.net/public_html/archive/openvpn-users/2005-05/msg00042.html on line 223
|