[Openvpn-users] learn address script

[Xen]

I have another issue where apparently my learn address script is called
for the host itself and a forwarded subnet.

Today I could not reach a host on the forwarded subnet. It was clear my
VPN server (openvpn) did not have the route for it.

It is just an iroute directive:

iroute 10.9.0.0 255.255.255.0

This causes this route to also be "learned" by the script.

It is these unreliablities that make it rather hard to use openvpn. I
don't yet know why today the route was not added. A VPN server restart
fixed it (the client automatically reconnects). But now I have to
monitor the routes and if they are not there I have to restart the VPN
server. Turns out I had a small bug in my script that caused some route
to not be deleted, but it shouldn't have prevented a route from being
added. So VPN was up but the route was not there.

I will have to monitor I guess whether it happens again. Otherwise... it
is hard for the server to monitor this without more code... but it's not
really the client's function to restart itself.

If my script had worked, there would be no route to the client at all,
because apparently the route that remained was only there because it had
not been deleted, not because it would subsequently have been added, so
the adding code had not executed properly after reconnect.

As in my other mail, there is again a php sendmail call that is
stalling.... :(. Cannot see how long it's been there. Annoying.

I guess I will have to wait until it happens again, otherwise it is time
for another cron job.... :(.

Regards.

[Gert Doering]

Hi,

Post by Xen
I have another issue where apparently my learn address script is called
for the host itself and a forwarded subnet.

learn-address is only called if the route is not already-known - so
if the client has previously connected, and the server did not notice
that it went away (no --ping and no explicit-exit-notify), it will
not tell you "delete first, add again right after" just keep it around.

But without logs from the server, it's hard to say what happened
exactly.

Post by Xen
It is these unreliablities that make it rather hard to use openvpn.

It's always nice to hear kind words from users :-)

gert

[Xen]

Post by Gert Doering
learn-address is only called if the route is not already-known - so
if the client has previously connected, and the server did not notice
that it went away (no --ping and no explicit-exit-notify), it will
not tell you "delete first, add again right after" just keep it around.

I know, but there had been a delete and not a add again. Maybe it was
related to a hanging connect script. I'll have to background it if this
php has the tendency to hang, because a blocking connect script also
blocks proper operation.

Better to just background all tasks that are not relevant for exit
status, I think.

Post by Gert Doering
But without logs from the server, it's hard to say what happened
exactly.

Aye, I'll have to wait. I couldn't make anything from the logs because
there is nothing written for "unlearn", so my script now gives that
output.

Post by Gert Doering

Post by Xen
It is these unreliablities that make it rather hard to use openvpn.

It's always nice to hear kind words from users :-)

Well openvpn works flawlessly when it does run. I've just had to create
a restart script on the client because otherwise it would stop
reconnecting; I didn't know how to fix it otherwise other than to just
run system-based restarts.

Today I spent at least 15 minutes trying to figure out why I couldn't
get to a VPN-internal host. :p.

At first I thought it was recent changes to my configuration system, but
that was not it. Took me a while to realize external hosts could access
it, but not me ;-). I'm just a bit fed up with those kinds of
troubleshooting sessions ;-).

Been trying to get this working for several years now lol.

Or when my learn address script would get fed the IP addresses of the
hosts behind the forwarded subnet ;-).

Suddenly the DNS of the client pointed to a host behind it, because my
version of OpenVPN running there on that server sends learn-address
messages each time that forwarded host is getting accessed. So I have to
verify it is the same as ifconfig_pool_remote.

Regardless I don't think openvpn ever fails in its operation, it is just
the management around it that makes it stop working now and then which
is just a headache. I wouldn't ever want to use anything else but now I
have restart scripts on the client and soon maybe also on the server :p.

Maybe it is the job of monitoring scripts to ensure proper operation
anyway. Regardless of which software you use.

Anyway.

The reason I send a message to the list is precisely because of that
headache ;-).

I absolutely love openvpn but the management headache became a bit too
much now, sorry.

Regards.

[Jan Just Keijser]

Hi,

Post by Xen

Post by Gert Doering
learn-address is only called if the route is not already-known - so
if the client has previously connected, and the server did not notice
that it went away (no --ping and no explicit-exit-notify), it will
not tell you "delete first, add again right after" just keep it around.

I know, but there had been a delete and not a add again. Maybe it was
related to a hanging connect script. I'll have to background it if this
php has the tendency to hang, because a blocking connect script also
blocks proper operation.
Better to just background all tasks that are not relevant for exit
status, I think.

Post by Gert Doering
But without logs from the server, it's hard to say what happened
exactly.

Aye, I'll have to wait. I couldn't make anything from the logs because
there is nothing written for "unlearn", so my script now gives that
output.

Post by Gert Doering

Post by Xen
It is these unreliablities that make it rather hard to use openvpn.

It's always nice to hear kind words from users :-)

Well openvpn works flawlessly when it does run. I've just had to create
a restart script on the client because otherwise it would stop
reconnecting; I didn't know how to fix it otherwise other than to just
run system-based restarts.
Today I spent at least 15 minutes trying to figure out why I couldn't
get to a VPN-internal host. :p.
At first I thought it was recent changes to my configuration system, but
that was not it. Took me a while to realize external hosts could access
it, but not me ;-). I'm just a bit fed up with those kinds of
troubleshooting sessions ;-).
Been trying to get this working for several years now lol.

if all external hosts can reach the server but you (internal host? vpn
server?) then it's - as always - a routing or NATting issue.
<shameless plug>
This _IS_ covered in a recipe of my OpenVPN cookbook
</shameless_plug>

Post by Xen
Or when my learn address script would get fed the IP addresses of the
hosts behind the forwarded subnet ;-).
Suddenly the DNS of the client pointed to a host behind it, because my
version of OpenVPN running there on that server sends learn-address
messages each time that forwarded host is getting accessed. So I have to
verify it is the same as ifconfig_pool_remote.
Regardless I don't think openvpn ever fails in its operation, it is just
the management around it that makes it stop working now and then which
is just a headache. I wouldn't ever want to use anything else but now I
have restart scripts on the client and soon maybe also on the server :p.
Maybe it is the job of monitoring scripts to ensure proper operation
anyway. Regardless of which software you use.

95% of the questions on the openvpn mailing list and forums are about
routing; usually it is fairly straightforward to get OpenVPN itself up
and running, but integrating it into your existing network setup is
harder. And this is not something that OpenVPN can/should do, IMHO.
OpenVPN is for securing connections between client and server.
Everything else is routing.

JM2CW,

JJK

[Xen]

Post by Jan Just Keijser

Post by Xen
Been trying to get this working for several years now lol.

if all external hosts can reach the server but you (internal host? vpn
server?) then it's - as always - a routing or NATting issue.
<shameless plug>
This _IS_ covered in a recipe of my OpenVPN cookbook
</shameless_plug>

No I got the routing set up and it works as usual normally but I add the
routes using a learn-address script for each individual host because
that allows me to combine tcp and udp on the same subnet.

I just can't diagnose this properly now but the routes had been
"unlearned" and then upon reconnect not "relearned". I was just
wondering if there was any default wisdom in knowing what to do about
these events.

Also it seems obvious to me now to ensure the thing doensn't hang (the
scripts you issue).

So the routingt is actually okay but I am having difficulty in ensuring
reliablity in those "context" things.

So: the thing generally works perfectly, but it doesn't always work
perfectly.

It's more the "init scripts" section that seems to be failing for me.

I....

Don't really know if I'm doing it right, but....

I have two different sections in the client config, one for udp and one
for tcp.

It first tries udp, then it tries tcp, but I don't really know how I can
get it to "recycle" back to udp.

Eventually I found that eventually the thing will stop reconnecting.

I don't know why or how to configure that so I started running
host-based restart scripts in the end.

Because no matter how perfectly openvpn really operates, I would find
that my VPN had been down for several days and my backups didn't run and
stuff like that, because the client daemon had stopped reconnecting
after some disconnect....

This time with the leanr address thing the route had not been set up
like it usually would and I didn't really know what caused it unless
maybe some hanging connect script or something.

I have a perfectly adequate setup but I don't know the mechanics of what
happens when some script hangs.

Regards.

[Xen]

This post might be inappropriate. Click to display it.

[Gert Doering]

Hi,

Post by Xen
But I don't know, it was just a temporary glitch.
But the temporary glitch caused the connection to be dropped...

If the server tells the client "your auth is not valid", yes, that
would cause the client to disconnect...

The TLS channel is renegotiated ever so often (more often if you use
BF-CBC), and the server will check auth every single time - and if
there is a "glitch", it has the same effect as a user account in radius
that is no longer valid - "go away, I do not trust you".

Using "auth-retry nointeract" might be what you need on the client side
to work karound this.

gert

[Xen]

Post by Gert Doering
Hi,

Post by Xen
But I don't know, it was just a temporary glitch.
But the temporary glitch caused the connection to be dropped...

If the server tells the client "your auth is not valid", yes, that
would cause the client to disconnect...
The TLS channel is renegotiated ever so often (more often if you use
BF-CBC), and the server will check auth every single time - and if
there is a "glitch", it has the same effect as a user account in radius
that is no longer valid - "go away, I do not trust you".
Using "auth-retry nointeract" might be what you need on the client side
to work karound this.

Amazing! My apologies, I wish I would have asked for help sooner...