|
|
> What about something like:
>
> ping 15
> ping-restart 120
>
> push "ping 15"
> push "ping-restart 60"
>
> This will shut down the client instance on the server after 2 minutes without
> a ping from the client, and will SIGUSR1 the client after 1 minute without
> anything being heard from the server.
This will work, but if I understand it correctly, it means when a client,
for example, closes his laptop, walks over to a conference room meeting,
then resumes laptop, he'll have to wait for one minute (at one minute
increments) to do anything, right? When running 1.5.0 the connection came
up almost immediately -- very nice. But... this may be a feature of
1.5.0's p2p nature, each side having a "remote" directive... I'd like to
be able to figure out a way to achieve a similar resilliency to
interruption. I thought the "ping" statement would keep it up, no? For
example, on the client if I did
ping 5
ping-restart 8
wouldn't this make it so the client *never* SIGUSR1's (becuase it'll ping
before the restart timer expires) unless the server is really unreachable?
Also, if I'm ping-restart'ing on the server, what are the implications w/
lots of clients? Will it maintain a separate timer foreach client?
> This is a feature not a bug :) The backslash is used as a kind of shell
> escape flag, for doing such things as sending a double quote char to a script.
Makes sense. I was just wondering about it because in 1.5.0, escaping the
path backslashes didn't seem to be needed. No biggie.
> The .2 is the "endpoint" of the server side tun/tap interface. Think of the
> OpenVPN server itself as owning the .2 address, since OpenVPN in this mode is
> acting as a router. If you route something to 10.8.0.2, it will end up in
> OpenVPN's lap, which will in turn route it to a client.
Ok, so the server owns the entire /30, both local and remote ends of the
tunnel. Two follow up questions:
a. Are you saying when we want to have client to client communication,
their nexthop should be set to .2?
b. From client's perspective, the only server ip I can ping is 10.8.0.1
(or, using my config files below, 192.168.200.1). Ping'ing .2 gives a
Request Time Out. Also, the client can't ping the remote side of his tun
instance. Again using my setup below, for example if a client comes up
and the server gives him 192.168.200.6 (w/ 192.168.200.5 as the "server"
side of the tun) out of the pool, the client can't ping .5 -- he can only
ping .1. Is this correct behavior?
> > b. "push 'route 10.8.0.1 255.255.255.255'" -- What is this for? If the
> > clients are doing "redirect-gateway", is this particular push statement
> > needed? Is it trying to push some sort of default route to client?
>
> This allows any client to use the IP 10.8.0.1 to communicate with the server
> over the VPN. It's not needed if all the clients are doing redirect-gateway.
I guess what I would like to know is what the default gateway needs to be.
For example, using this setup
server
tun0 = 192.168.200.1 -> 192.168.200.2 /30
client
tun0 = 192.168.200.6 -> 192.168.200.5 /30
what should client's default gateway be, .5 or .1 -- or even .2? On
Windows client, when I use "redirect-gateway", .5 becomes the default
gateway. Here's the routing table before and after I start
openvpnservice:
BEFORE
******
Network Destination Netmask Gateway Interface Met
0.0.0.0 0.0.0.0 10.1.1.1 10.1.1.10 1
10.1.1.0 255.255.255.0 10.1.1.10 10.1.1.10 30
10.1.1.10 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.1.1.10 10.1.1.10 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.200.4 255.255.255.252 192.168.200.6 192.168.200.6 30
192.168.200.6 255.255.255.255 127.0.0.1 127.0.0.1 30
192.168.200.255 255.255.255.255 192.168.200.6 192.168.200.6 30
224.0.0.0 240.0.0.0 10.1.1.10 10.1.1.10 30
224.0.0.0 240.0.0.0 192.168.200.6 192.168.200.6 30
255.255.255.255 255.255.255.255 10.1.1.10 10.1.1.10 1
255.255.255.255 255.255.255.255 192.168.200.6 192.168.200.6 1
255.255.255.255 255.255.255.255 192.168.200.6 10004 1
Default Gateway: 10.1.1.1
=======================================================================
Persistent Routes:
None
AFTER
*****
Network Destination Netmask Gateway Interface Met
0.0.0.0 0.0.0.0 192.168.200.5 192.168.200.6 1
10.1.1.0 255.255.255.0 10.1.1.10 10.1.1.10 30
10.1.1.1 255.255.255.255 10.1.1.10 10.1.1.10 1
10.1.1.10 255.255.255.255 127.0.0.1 127.0.0.1 30
10.255.255.255 255.255.255.255 10.1.1.10 10.1.1.10 30
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.200.1 255.255.255.255 192.168.200.5 192.168.200.6 1
192.168.200.4 255.255.255.252 192.168.200.6 192.168.200.6 30
192.168.200.6 255.255.255.255 127.0.0.1 127.0.0.1 30
192.168.200.255 255.255.255.255 192.168.200.6 192.168.200.6 30
224.0.0.0 240.0.0.0 10.1.1.10 10.1.1.10 30
224.0.0.0 240.0.0.0 192.168.200.6 192.168.200.6 30
255.255.255.255 255.255.255.255 10.1.1.10 10.1.1.10 1
255.255.255.255 255.255.255.255 192.168.200.6 192.168.200.6 1
255.255.255.255 255.255.255.255 192.168.200.6 10004 1
Default Gateway: 192.168.200.5
=======================================================================
Persistent Routes:
None
But I can't ping .5!
> > 4. If I want to keep everything as generic as possible, configuration
> > file-wise, what is the best way (or a good way) to propagate the client's
> > default gateway w/out having to specify an actual IP addr? The only way I
> > was able to get this to work is by using "redirect-gateway" and
> > "route-delay 0" together. I'm not so sure this is a good thing, at least
> > the route-delay part, as I am trying to dhcp everything, both the real
> > and virtual interfaces...
>
> What happens without "route-delay 0"?
W/out "route-delay 0" the routes never get installed. The logs indicate
that a "Successful ARP flush" occurs, then a "Inactivity timeout
(--ping-restart), restarting...". I just loop in this forever. Again,
this seems to be related to my attempt to make the connection resillient
to interruptions, hence the --ping-restart. Maybe I should play w/ less
aggressive timer values... but this comes at the cost of improved
resilliency.
Thanks again for your help!
-Adam
> > ----------------server----------------
> > dev tun0
> > local 10.1.1.1
> > port 5000
> >
> > mode server
> > client-to-client
> >
> > ifconfig 192.168.200.1 192.168.200.2
> > ifconfig-pool 192.168.200.4 192.168.200.251
> > route 192.168.200.0 255.255.255.0
> > inactive 600
> >
> > tls-server
> > dh /usr/local/etc/openvpn/certs/CA/dh1024.pem
> > ca /usr/local/etc/openvpn/certs/CA/CA.crt
> > cert /usr/local/etc/openvpn/certs/gw-wifi.crt
> > key /usr/local/etc/openvpn/certs/gw-wifi.key
> >
> > comp-lzo
> >
> > verb 3
> > --------------------------------------
> >
> > ----------------client----------------
> > dev tun
> > remote 10.1.1.1
> > port 5000
> >
> > pull
> >
> > redirect-gateway
> > route-delay 0
> >
> > tls-client
> > ca CA.crt
> > cert vega.crt
> > key vega.key
> > comp-lzo
> >
> > ping 10
> > ping-restart 5
> >
> > verb 3
> > mute 10
> > --------------------------------------
> >
> > -Adam Richards
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Sleepycat Software
> > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
> > higher performing products faster, at low TCO.
> > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> > _______________________________________________
> > Openvpn-users mailing list
> > Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/openvpn-users
> >
>
>
>
> --
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
> higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
>
|