[Openvpn-users] Re: [Openvpn-devel] OpenVPN 2.0 iroutes

[James Yonan <jim@xxxxxxxxx>]

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
> >
> 

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users