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

[James Yonan <jim@xxxxxxxxx>]

On Wed, 4 May 2005, Dan Hulme wrote:

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

There shouldn't be a delay.  The server should immediately read the ccd 
file when the client reconnects.  Make sure you are using "nobind" on the 
clients.  And you can use a lower timeout on the keepalive directive.

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

The reason why iroute does not automatically add an equivalent system
route as well is that OpenVPN is designed to drop root privileges after
initialization, so it would not have the required privileges to add a
route after initialization.  The privilege model dictates that system
routes be statically added on initialization while iroutes are added and
removed during normal VPN operation as clients connect and disconnect.

James

 > 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> <http://192.168.1.1>, but not from
> > > 192.168.1.2 <http://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> <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