Re: [Openvpn-users] OpenVPN ports

[Xen]

Aziz schreef op 12-10-2017 11:02:


Thank you all.

I will do further testing/troubleshooting .


Make sure you didn't just misunderstand the port forwarding dialogue of 
your router.


Some routers these days, particularly from ISPs (modems) have rather 
unintuitive interfaces that can throw you into confusion.


Regards.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] OpenVPN ports

[Xen]

Aziz schreef op 12-10-2017 10:32:


Hi All,

I'm using OpenVPN server behind NAT (Firewall), I need to know which 
ports to open in order to allow clients to connect to my OVPN server. 
In other words what are the defaults ports used by an OVPN server ?


That means the only port you need is 1194, either tcp or udp.

The management port is generally 1195 if configured. But this would then 
only be available to you inside the network, or inside the host.


You can test on your server, if it is configured with:

telnet localhost 1195.

If it connects, you then have commands like:

status -- to show the list of connected clients
kill   -- to kick a client.



But that is not something you need to forward, so there is really only 
one port, like Antonio mentioned.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] changes from 2.3 to 2.4 (client)?

[Xen]

Jan Just Keijser schreef op 03-10-2017 17:18:


what does it say in the client-side logs when this is pushed?


Not very special but I can paste later.


And are you specifying "topology subnet" on the server side? then that
get's pushed to the clients also.


Yes I have tried all 3 combinations like I said; both on the server and 
on the client.



it could also have been the client-side config file ;)


I think you should assume that something makes sense what someone says 
;-).


:p.


Add "route 10.3.0.0 255.255.255.0" to the server-side config file
(main config file) to ensure that the routing table is also updated
each time OpenVPN starts and stops.


This is done by the learn-address script.


Also, check that IP forwarding is enabled (I would assume so
already).


Of course.


Then, finally, post the routing tables once the VPN
server+client are up.


I've already done so basically.


Run tcpdump (e.g. on the server) to see where
packets are getting lost between subnet-behind-server vs
subnet-behind-client.


When I did this I was unfortunately checking the wrong IP ;-) 
(192.168.0.1 instead of 0.3).


It was pretty obvious the router (0.1) would not return fire as it has 
no appropriate routes (these ISP modems you cannot configure).


But like I said after about 7 minute last time I tried, the proper 
'link' came up.


That means RIGHT NOW everything is working.

If I now restart the client it will probably take a few minutes again 
before everything is working; by it takes this long I do not know.


But the experience at THIS MOMENT is that AFTER THOSE 7 minutes, it 
keeps working indefinitely.


I mean this is the ping from the PC:

Pinging 10.3.0.2 with 32 bytes of data:
Reply from 10.3.0.2: bytes=32 time=152ms TTL=62
Reply from 10.3.0.2: bytes=32 time=10ms TTL=62
Reply from 10.3.0.2: bytes=32 time=8ms TTL=62
Reply from 10.3.0.2: bytes=32 time=10ms TTL=62

Ping statistics for 10.3.0.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 152ms, Average = 45ms

But right now my server is in a bit of a mess because I had a hellish 
time trying to upgrade Debian to version 9


( partly my fault for not recognising an earlier bug in my server, but 
several packages have been dropped from Debian that I used etc... )


So I don't feel much like troubleshooting because there are more serious 
things on my mind...


But the only thing I could show you was the client log and the tcpdump 
on the server as the 10.3.0.2 client tries to reach the 192.168.0.3 IP.


But that can wait ;-).

Regards.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

Theo Fokkema schreef op 03-10-2017 13:40:
AirVPN uses its own tool they call "Eddie" which will do latency tests 
and connect to a recommended server, but which will also allow you to

manually choose one.


I guess there is a 'market' for an open tool that does the same for
corporate networks then.


You can also let the 'fake' VPN server just not give out any routes to 
the company network, which you can do with a client-config-script.
At that point the VPN is only used for the VPN, but if your VPN 
clients normally only use the VPN to get to the normal company network 
(ie. you > don't stay on the VPN with your data) then connecting to 
the VPN (with no default route) does no damage.


It would still lead to IP address depletion (we mostly use /24 subnets
with DHCP configured to have a pool of 150 IP addresses available, in
our larger offices we might have more than 75 users connected
simultaneously).



I could of course work around that by making the VPN
a different routed (or not routed at all, if I read you correctly)
subnet, but would prefer to stick with bridging for now.


Oh yes apologies, I have no experience with bridged VPN.

I assumed you put them on an entirely different subnet and then routed 
to the main ones.


I guess doing routed requires you to employ routes to the VPN 
everywhere, but the benefit is that you can distinguish pool users 
easier.



But it looks like we can't have it all, for now...


The only choice then it to prevent them from connecting.

Or like the other person said...

You give them a routed different subnet address when in the office that 
is then not used. He said it was far from ideal?


Personally I think routed is better but that's just me.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

Theo Fokkema schreef op 03-10-2017 12:33:

I'd have to hire a programmer to write a separate service that wraps 
around the OpenVPN service, probably.


But I can hardly imagine that I'm the first person to want such a 
setup. Are any such wrappers or scripts existing?


I noticed there are a number of public VPN providers who provide 
internet privacy by setting up a VPN between client and an anonymous 
internet connection. Many of these use OpenVPN.


How do they do autoselect?


AirVPN uses its own tool they call "Eddie" which will do latency tests 
and connect to a recommended server, but which will also allow you to 
manually choose one.


Someone suggested 'fake VPN' connections from within the office, with 
the only drawback being users seeing VPN error messages.


I thought of another 'dirty' solution, but it will probably also 
generate lots of errors on the road warriors' laptops:


Suppose I create a separate dns entry openvpn.companyname.com on the 
public (internet) DNS and configure my clients to connect to that, and 
then I could create the same entry in the LAN's (internal) DNS to point 
to a nonexisting server, or a server declining the connection or not 
handing out IP's.

But that is really dirty, right?


I don't see why it's necessary. But I guess it could work.

You can also let the 'fake' VPN server just not give out any routes to 
the company network, which you can do with a client-config-script.


At that point the VPN is only used for the VPN, but if your VPN clients 
normally only use the VPN to get to the normal company network (ie. you 
don't stay on the VPN with your data) then connecting to the VPN (with 
no default route) does no damage.


That means the "useless" VPN will barely get used, while in the office.

It won't give out routes to your company LAN.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] changes from 2.3 to 2.4 (client)?

[Xen]

Jan Just Keijser schreef op 03-10-2017 11:29:


On 02/10/17 19:17, Xen wrote:
So it appears that by upgrading a client to 2.4 something stopped 
working.


I have a rather old Synology server.

Version is 2.1.4

Topology is as follows:

Home network --> VPN server --> VPN client --> client behind client

Home network (my computer) has a route for the VPN and a route for the 
client behind client.


 10.3.0.0    255.255.255.0 192.168.0.3 192.168.0.100 
26

    10.8.0.0    255.255.255.0 192.168.0.3 192.168.0.100 26


Well I guess it is cryptic, but this is the route for the regular PC via 
the VPN server which is in this case 192.168.0.3



The client config file is as follows:

ifconfig-push 10.8.0.25 255.255.255.0
iroute 10.3.0.0 255.255.255.0
push 'route 192.168.0.0 255.255.255.0'

Before, I used no topology. I did use the above. Now the 2.4 client 
expects a p2p topology by default and complains about the above 
ifconfig-push directive.


I assume the iroute is currently not working.

What topology should I use? I now forced it to "subnet".


the 'iroute' does not do anything on the client, that's a server
statement. The 'ifconfig-push' should have worked with OpenVPN 2.4.


Ehm, I thought it would be obvious that this is a file on the server in 
the client-config-dir.


That's why I call it a client-config-file.


Try adding an
  iroute 10.3.0.0. 255.255.255.0
to a CCD file named 'bugger' inside the *SERVER* config, so that the
VPN server knows that the network 10.3.0.0 is to be found "behind" the
VPN client 'bugger', e.g


Well like I said this was already the case. It would not have worked at 
all if this was not true.



And add "client-config-dir /etc/openvpn/clients" to the VPN server
config.


I have that.


Also, check
that the CCD file is picked up by the server by running with "verb 5"
and look for any references to client-config files.


It was my entire client config file.

But thanks for responding ;-).

Kudos.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

Jan Just Keijser schreef op 03-10-2017 10:52:

Actually, this is not a requirement. You can set up a PKI (Public Key 
Infrastructure) like this:



Root CA   Server sub-cA  --- Server cert


Yes and you can have more than one Server cert.


|
+ Office 1 sub-ca --- Office 1 clients
|
+ Office 2 sub-ca --- Office 2 clients


You can also use a client-connect script to NOT push out a default 
gateway if a client is on a (trusted) LAN; that
way, the clients will still have a VPN IP address, they simply won't 
route any traffic over it by default.


I assumed this would be the case. I don't think you want to connect to 
the internet via your company VPN whenever and wherever you use it, but 
rather to only have access to company networks right?


I think what that other person meant was that a 0.0.0.0 route would get 
trumped by more specific subnet routes.


My only suggestion was that it was easy enough to give out specific 
subnet routes for the company, which can then have a lower metric than 
the equally specific subnet routes obtained via VPN.


Ie. you already get routes when you connect to DHCP. If your laptop then 
connects to VPN as well, you get the same routes twice. (Of course you 
could also not send out those routes over VPN when the client is 
connecting from the company LAN).


But there are just a myriad of solutions that all seem pretty 
reasonable.


There is no need to crack down on any of it. This is feasible.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

I am sorry this will be my last message.

This is bullshit.

Илья Шипицин schreef op 02-10-2017 21:26:

yes, if you distribute all of your organization routes via DHCP - it is 
good.

but it is not common practice


Then you throw away a solution just to be able to call something else 
bad.


If it is common practice not to build any railroads, then suddenly 
trains seem like a bad solution.


If all of your company's subnets are on a single segment, ie. 
192.168.X.0 then you can reach all of them with 192.168.0.0/16.


You would probably only require one additional route in addition to your 
default route.


And this is only required for VPN clients; ie. probably only those 
laptops people bring in.


So if the cost of this solution is to give every VPN client (if that's 
possible) one extra route then that's not a huge cost to pay if the only 
concern is that those laptops can reach other floors through the normal 
gateway instead of the VPN server that is sitting right next to it...


Which is probably not a huge problem to begin with...
...and if the solution only targets VPN laptops, then it seems also a 
fine solution to me.


It is clear the problem is solvable...

Saying "Yeah but it is not perfectly ideal" doesn't mean much.

The alternative is having no automatic VPN login,

Or Windows scripting to make choices based on what network one is in, 
which requires a lot of development, installation on every laptop, and 
so on.


You will need to build your own Windows client, preferably not just a 
script. It will have to run as a Windows service.


Doable if you can make it a nice thing. Then it can also perform the 
function of selecting the nearest server.


But you won't have this done in 30 hours.

So dispensing one extra route to VPN clients (could simply be based on 
MAC addresses?) seems a very easy short-term solution that requires less 
maintenance until you have a fully-fledged service you can deploy in an 
automated fashion, then it doesn't... matter anymore as much, but a 
server-based solution is still a better choice I feel.


You could also only dispense this route to Wifi clients for instance.

It is zero configuration on the client, if you give it to wifi clients 
it is easy on the server, if you don't you require maybe a database of 
MAC addresses.


And for no other reason than to reach other floors a little bit more 
efficiently.


Deploying a centrally distributed service for installation on all 
laptops is a long term goal.


This solution however you have implemented in a day.

If it's not common practice, it can become one. ( I mean what is that 
for kind of retort? ).



Become equivalent and can compete in terms of metric.


it is equivalent in terms of metric, however, next floor is better to 
be accessed via local gateway, not a vpn gateway


No I did not say it was equivalent in terms of metric.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

Илья Шипицин schreef op 02-10-2017 21:00:


LAN1  and LAN2 are just different floors in a single building.


I don't know where you get that idea.

If a VPN only provides gateway for VPN connected devices that's one 
thing.

If a VPN provides routes for LANS that's another thing.

Those routes can be equivalent to ordinary ones. Ie.

192.168.0.0/24 dev eth0  src 192.168.0.30

Is a direct route to the network a client is on.

If

192.168.1.0/24 is a different subnet, then it requires routing.

192.168.1.0/24 via 192.168.0.1 dev eth0

Now you can suggest that this route doesn't exist. Then you can add it. 
DHCP clients are capable of delivering additional routes. If it ever 
became a problem, the server can just give those routes to every client.


So your VPN routes:

192.168.0.0/24 via 10.8.0.1 dev tun0
192.168.1.0/24 via 10.8.0.1 dev tun0

Become equivalent and can compete in terms of metric.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] changes from 2.3 to 2.4 (client)?

[Xen]

Xen schreef op 02-10-2017 19:48:


I don't understand why routing from

192.168.0.0 to 10.3.0.0  suddenly doesn't work anymore?


Now suddenly I have a connection again. I changed nothing.

So I restart the VPN client.

Again no connection.

Already 5 minutes in.

Now there is a connecting with the LAN-IP of the server (192.168.0.3)

But not my computer (.100).

Now that one is back too.

This took 7 minutes since restart :-/.

There IS evidence of iroute activity now and then in the logs:

Mon Oct  2 20:58:11 2017 bugger/149.201.238.25:1194 MULTI: Learn: 
10.3.0.2 -> bugger/149.201.238.25:1194
learn-address: OpenVPN thinks it's funny by giving me fake addresses 
constantly.
Mon Oct  2 21:01:51 2017 bugger/149.201.238.25:1194 MULTI: Learn: 
10.3.0.2 -> bugger/149.201.238.25:1194


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

Илья Шипицин schreef op 02-10-2017 20:08:


2017-10-02 22:40 GMT+05:00 Xen :


Илья Шипицин schreef op 02-10-2017 19:31:

consider the following setup

office
LAN1: 192.168.100.0/24
LAN2: 192.168.101.0/24

user only use default gateway, it serves both internet and LAN2 (when 
user in LAN1)


if user connects to vpn, it will route to LAN2 through vpn gateway (it 
wins over default route)

---

Yes and they will still route to LAN1 and internet via default route.


that's what I meant.

no vpn connected (from office) - both LAN1, LAN2 are accessed via 
default route (it is good)


vpn connected (from office) - LAN2 is accessed via vpn (it is rather 
undesirable, but still should work)


Directly accessing LAN1 will not go over VPN, so any access to the 
company network will be direct.


Only if you access VPN hosts will it through the VPN server, but this is 
the only possibility anyway.


You cannot directly speak to VPN clients. You have to go through the 
server.


So I don't see what the issue is.

It's a great idea.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] changes from 2.3 to 2.4 (client)?

[Xen]

Xen schreef op 02-10-2017 19:17:


What did I do?


I am apparently mistaken. The same thing happens with the 2.3 client 
now.


I have tried:

  - net30 on both client and server, ifconfig-push 10.8.0.25 10.8.0.24
  - subnet on both client and server, ifconfig-push 10.8.0.25 
255.255.255.0

  - p2p on both client and server, ifconfig-push 10.8.0.25 10.8.0.24

And the strange thing is that before I started troubleshooting (the 
learn/unlearn thing) it still worked.


So before I restarted the openvpn client, I did have a connection 
between those computers.



I also updated a few packages on the client but this couldn't cause the 
problem right...


I don't understand why routing from

192.168.0.0 to 10.3.0.0  suddenly doesn't work anymore?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

Илья Шипицин schreef op 02-10-2017 19:31:

 consider the following setup

office
LAN1: 192.168.100.0/24
LAN2: 192.168.101.0/24

user only use default gateway, it serves both internet and LAN2 (when 
user in LAN1)


if user connects to vpn, it will route to LAN2 through vpn gateway (it 
wins over default route)

---

Yes and they will still route to LAN1 and internet via default route.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

Илья Шипицин schreef op 02-10-2017 18:41:


This is a great idea.



I do not think so.
consider a "road" warrior" with a laptop



1) when in office, usually you get 0.0.0.0/0 route, i.e. default


2) when connected via vpn, you get a bunch of routes via vpn and 
0.0.0.0/0 via local ISP.


any non-default route will win because of shorter network mask no 
matter what routing metric is.


Non-default routes only serve non-default targets.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] changes from 2.3 to 2.4 (client)?

[Xen]

So it appears that by upgrading a client to 2.4 something stopped 
working.


I have a rather old Synology server.

Version is 2.1.4

Topology is as follows:

Home network --> VPN server --> VPN client --> client behind client

Home network (my computer) has a route for the VPN and a route for the 
client behind client.


 10.3.0.0255.255.255.0 192.168.0.3   192.168.0.100 
26

10.8.0.0255.255.255.0 192.168.0.3   192.168.0.100 26

VPN server has a route for home network, VPN client and client behind 
client:


10.8.0.25 dev tun0
192.168.0.0/24 dev eth0  src 192.168.0.3
10.3.0.0/24 via 10.8.0.25 dev tun0

As well as for the VPN entire:

10.8.0.0/24 dev tun0  src 10.8.0.1
10.8.0.0/24 dev tun1  src 10.8.0.1

VPN client has a route for home network, internal client, and VPN:

10.3.0.0/24 dev lxc-nat-bridge  proto kernel  scope link  src 10.3.0.1
10.8.0.0/24 dev tun0  proto kernel  scope link  src 10.8.0.25
192.168.0.0/24 via 10.8.0.1 dev tun0

And the client behind the client only has one route:

default via 10.3.0.1 dev eth0

Now normally this works fine.

Currently the:

  - home computer can reach the vpn client
  - vpn client can reach the home computer
  - internal host (10.3.0.2) can reach the VPN address of the server 
(10.8.0.1)


But that's where it ends. The internal client (10.3.0.2) is unable to 
reach the home network and vice versa.


The client config file is as follows:

ifconfig-push 10.8.0.25 255.255.255.0
iroute 10.3.0.0 255.255.255.0
push 'route 192.168.0.0 255.255.255.0'

Before, I used no topology. I did use the above. Now the 2.4 client 
expects a p2p topology by default and complains about the above 
ifconfig-push directive.


I assume the iroute is currently not working.

What topology should I use? I now forced it to "subnet".

I prefer subnet or net30 I think, but net30 apparently also wants an 
end-point (IP) in the ifconfig-push directive.


I don't know what can be going on.

What did I do?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] fix disconnect connect order in address learning/unlearning

[Xen]

Jan Just Keijser schreef op 02-10-2017 17:00:


are you using "proto udp" ?


Yes I am using both but normally it would connect via UDP.


if so, add "explicit-exit-notify 3" to the
client config (or 'push "explicit-exit-notify 3" ' to the server
config). That way, a client always sends a disconnect message. In TCP
mode this is not necessary.


Well the problem was when the client DID send a disconnect message.

If a disconnect message was not received usually the learn-address 
script is not even invoked when the client returns.


But I'll try to see if it makes a difference.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Select nearest OpenVPN server / shared userbase / Only connect if away from home

[Xen]

Jan Just Keijser schreef op 02-10-2017 17:04:

2. Is there a way to have different OpenVPN servers share (or 
synchronize) the same certificates so we only have to create one 
certificate for each user to have access to all our OpenVPN servers 
worldwide? Or entirely validate through Active Directory only 
(probably combined with a single certificate)

yes. this is possible: you can have a single CA to hand out
certificates for all clients, or you can even create sub-CA's for each
office so that each office can hand out certificates which are then
trusted by all other offices.


What they mean is you wouldn't be validating against a single cerficiate 
or a certain known certificate.


Your client would accept all server certificates as valid that derive 
from a central CA, that you can be yourself.



Also, I'd recommend to put the VPN clients in a separate DHCP pool /
IP range, in which case it does not really matter if a laptop obtains
an extra IP address. That way, a laptop may receive an VPN IP address
but dependent on routing metrics the LAN connection would prevail.
If you need more control than this, then this would require a wrapper
around OpenVPN itself.


This is a great idea.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] fix disconnect connect order in address learning/unlearning

[Xen]

Hi,

I just initiated a client-reset (restart) on my client.

The result was this (below):

What happened was that a concurrent disconnect and connect sequence was 
going on with respect to learn-address and the learn beat the unlearn.


I don't know exactly what is going on but...

Is there any way to make sure the disconnect sequence completes first 
before the connect sequence is started?


Regards,

Xen.




Sun Oct  1 14:31:01 2017 bugger/149.102.238.25:36628 Connection reset, 
restarting [0]
Sun Oct  1 14:31:01 2017 bugger/149.102.238.25:36628 
SIGUSR1[soft,connection-reset] received, client-instance restarting

Sun Oct  1 14:31:01 2017 MULTI: multi_create_instance called
Sun Oct  1 14:31:01 2017 149.102.238.25:1194 Re-using SSL/TLS context
Sun Oct  1 14:31:01 2017 149.102.238.25:1194 LZO compression initialized
Sun Oct  1 14:31:01 2017 RADIUS-PLUGIN: BACKGROUND ACCT: No accounting 
data was found for bugger,149.102.238.25:36628.
Sun Oct  1 14:31:01 2017 149.102.238.25:1194 Control Channel MTU parms [ 
L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Oct  1 14:31:01 2017 149.102.238.25:1194 Data Channel MTU parms [ 
L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Sun Oct  1 14:31:01 2017 149.102.238.25:1194 Local Options hash 
(VER=V4): '530fdded'
Sun Oct  1 14:31:01 2017 149.102.238.25:1194 Expected Remote Options 
hash (VER=V4): '41690919'
Sun Oct  1 14:31:01 2017 149.102.238.25:1194 TLS: Initial packet from 
149.102.238.25:1194, sid=732e0773 2ebcc88f
Sun Oct  1 14:31:01 2017 PLUGIN_CALL: POST 
/var/packages/VPNCenter/target/lib/radiusplugin.so/PLUGIN_CLIENT_DISCONNECT 
status=0

Sun Oct  1 14:31:01 2017 RADIUS-PLUGIN: FOREGROUND THREAD: New user.
client-disconnect: Sending disconnect email for bugger
Sun Oct  1 14:31:02 2017 RADIUS-PLUGIN: No attributes Acct Interim 
Interval or bad length.
Sun Oct  1 14:31:02 2017 RADIUS-PLUGIN: Client config file was not 
written, overwriteccfiles is false
.Sun Oct  1 14:31:02 2017 RADIUS-PLUGIN: FOREGROUND THREAD: Add user to 
map.
Sun Oct  1 14:31:02 2017 149.102.238.25:1194 PLUGIN_CALL: POST 
/var/packages/VPNCenter/target/lib/radiusplugin.so/PLUGIN_AUTH_USER_PASS_VERIFY 
status=0
Sun Oct  1 14:31:02 2017 149.102.238.25:1194 TLS: Username/Password 
authentication succeeded for username 'bugger' [CN SET]
Sun Oct  1 14:31:02 2017 149.102.238.25:1194 Data Channel Encrypt: 
Cipher 'BF-CBC' initialized with 128 bit key
Sun Oct  1 14:31:02 2017 149.102.238.25:1194 Data Channel Encrypt: Using 
160 bit message hash 'SHA1' for HMAC authentication
Sun Oct  1 14:31:02 2017 149.102.238.25:1194 Data Channel Decrypt: 
Cipher 'BF-CBC' initialized with 128 bit key
Sun Oct  1 14:31:02 2017 149.102.238.25:1194 Data Channel Decrypt: Using 
160 bit message hash 'SHA1' for HMAC authentication
Sun Oct  1 14:31:02 2017 149.102.238.25:1194 Control Channel: TLSv1, 
cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA
Sun Oct  1 14:31:02 2017 149.102.238.25:1194 [bugger] Peer Connection 
Initiated with 149.102.238.25:1194
Sun Oct  1 14:31:02 2017 bugger/149.102.238.25:1194 OPTIONS IMPORT: 
reading client specific options from: client-config-dir/bugger
Sun Oct  1 14:31:02 2017 bugger/149.102.238.25:1194 PLUGIN_CALL: POST 
/var/packages/VPNCenter/target/lib/radiusplugin.so/PLUGIN_CLIENT_CONNECT 
status=0

Sun Oct  1 14:31:03 2017 TCP/UDP: Closing socket
Learn-address: adding route for host 10.8.0.25
Learn-address: adding DNS record for host 10.8.0.25
Sun Oct  1 14:31:05 2017 bugger/149.201.238.25:1194 MULTI: Learn: 
10.8.0.25 -> bugger/149.201.238.25:1194
Sun Oct  1 14:31:05 2017 bugger/149.201.238.25:1194 MULTI: primary 
virtual IP for bugger/149.201.238.25:1194: 10.8.0.25
Sun Oct  1 14:31:05 2017 bugger/149.201.238.25:1194 MULTI: internal 
route 10.3.0.0/24 -> bugger/149.201.238.25:1194

Learn-address: adding route for subnet 10.3.0.0/24
Sun Oct  1 14:31:06 2017 bugger/149.201.238.25:1194 MULTI: Learn: 
10.3.0.0/24 -> bugger/149.201.238.25:1194
Sun Oct  1 14:31:06 2017 bugger/149.201.238.25:1194 PUSH: Received 
control message: 'PUSH_REQUEST'
Sun Oct  1 14:31:06 2017 bugger/149.201.238.25:1194 SENT CONTROL 
[bugger]: 'PUSH_REPLY,ping 10,ping-restart 40,route 10.8.0.0 
255.255.255.0,topology net30,route 192.168.20.0 255.255.255.0,ifconfig 
10.8.0.25 10.8.0.1' (status=1)

Learn-address: removing route for host 10.8.0.25
Learn-address: removing DNS record for host 10.8.0.25
Learn-address: removing route for subnet 10.3.0.0/24


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Clients can't connect after server reboot

[Xen]

Mio Vlahović schreef op 08-08-2017 22:02:

On 08.08.2017 21:47, David Sommerseth wrote:

On 08/08/17 21:28, Mio Vlahović wrote:

On 08.08.2017 21:13, David Sommerseth wrote:

On 08/08/17 20:34, Leonardo Rodrigues wrote:


  You very likely created your certificated with MD5 hashing, 
which

was disabled on newer OpenSSL versions of CentOS.

  Try:

export NSS_HASH_ALG_SUPPORT=+MD5
export OPENSSL_ENABLE_MD5_VERIFY=1

  before starting your OpenVPN daemon and watch if that make 
clients

connect again ...

DON'T DO THAT.

MD5 based certificates are broken.  If you still use them, upgrade 
them

NOW.  And this knowledge about the brokenness dates back to 2005.




Anyone using MD5 and re-enables them in the SSL libraries will put 
their

VPN's security at risk.


No worries, I don't use MD5, but disabling crl_verify as suggested 
did
the trick. Now I still have the issue with generating new 
certificates.


I will quote myself again
"One update... I can no longer generate new certificates. It seemse 
that

whichopensslcnf scripts can't find openssl.cnf (which is there in the
same directory...)

[root@vpn 2.0]# pwd
/etc/openvpn/easy-rsa/2.0
[root@vpn 2.0]# ls -la
drwx--. 3 nobody nobody  4096 Aug  8 20:25 .
drwx--. 3 nobody nobody33 Feb  6  2016 ..
-rwx--. 1 nobody nobody   119 Feb  6  2016 build-ca
-rwx--. 1 nobody nobody   352 Feb  6  2016 build-dh
-rwx--. 1 nobody nobody   188 Feb  6  2016 build-inter
-rwx--. 1 nobody nobody   163 Feb  6  2016 build-key
-rwx--. 1 nobody nobody   157 Feb  6  2016 build-key-pass
-rwx--. 1 nobody nobody   249 Feb  6  2016 build-key-pkcs12
-rwx--. 1 nobody nobody   268 Feb  6  2016 build-key-server
-rwx--. 1 nobody nobody   213 Feb  6  2016 build-req
-rwx--. 1 nobody nobody   158 Feb  6  2016 build-req-pass
-rwx--. 1 nobody nobody   449 Feb  6  2016 clean-all
-rwx--. 1 nobody nobody   424 Feb  6  2016 dh2048.pem
-rwx--. 1 nobody nobody  1471 Feb  6  2016 inherit-inter
drwx--  2 nobody nobody 36864 Jul 26 15:07 keys
-rwx--. 1 nobody nobody   302 Feb  6  2016 list-crl
-rwx--. 1 nobody nobody  7791 Feb  6  2016 openssl-0.9.6.cnf
-rwx--. 1 nobody nobody  8348 Feb  6  2016 openssl-0.9.8.cnf
-rwx--  1 nobody nobody  8247 Aug  8 18:37 openssl-1.0.0.cnf
-rwx--  1 nobody nobody  8247 Aug  8 19:14 openssl.cnf
-rwx--. 1 nobody nobody 12966 Feb  6  2016 pkitool
-rwx--. 1 nobody nobody   928 Feb  6  2016 revoke-full
-rwx--. 1 nobody nobody   178 Feb  6  2016 sign-req
-rwx--  1 nobody nobody  2138 Aug  8 20:25 vars
-rwx--. 1 nobody nobody   740 Feb  6  2016 whichopensslcnf

root@vpn 2.0]# ./build-key xxx
grep: /etc/openvpn/easy-rsa/2.0/openssl.cnf 
/etc/openvpn/easy-rsa/2.0:

No such file or directory
pkitool: KEY_CONFIG (set by the ./vars script) is pointing to the 
wrong

version of openssl.cnf: /etc/openvpn/easy-rsa/2.0/openssl.cnf
/etc/openvpn/easy-rsa/2.0
The correct version should have a comment that says: easy-rsa version 
2.x"


Did you remember to source the ./vars file first?

$ . ./vars

(yes, a single dot and then ./vars)




Yes I did, same result... any other hints?


Add the comment it says it needs to have.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] Clients can't connect after server reboot

[Xen]

Mio Vlahović schreef op 08-08-2017 19:59:


Can anyone assist us on this one? I have googled and found something
about CRL has expired error. Is it related with the upgrade of the
openvpn package? we use one from the epel repository.


You know a CRL is a certificate revocation list right.

Being a layman for the rest of it, it means that your configuration uses 
a CRL to begin with. A CRL is supposed to regularly issued and 
containing a list of certificates that are no longer deemed trustworthy; 
ie. client certificates that have been compromised.


So you can do two things: renew your CRL, or remove it from the 
configuration.


I will let someone answer now who actually has something useful to say 
;-).


Regards.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] automatically restart openvpn

[Xen]

David Sommerseth schreef op 31-05-2017 18:28:


As you use systemctl, that implies systemd.  Then that hack is truly
ugly compared to what systemd provides.


You know David,

I just tried to use a simple Path file for something and then a simple 
Unit file (Service file) with systemd to send an email when that 
happened.


Fine, I didn't use any built-in email facility.

I used:

/bin/sh -c 'echo | /usr/bin/mail -s subject root'

And that simply didn't work.
The command worked from the shell, and the command works from a cron 
job.

But the command doesn't work from systemd.

It's systemd that's really ugly.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] automatically restart openvpn

[Xen]

Samuli Seppänen schreef op 31-05-2017 19:10:


Hi,

A few months back I looked into exactly this issue. Back then there was
no easy way to make systemd send emails. That is why I still use monit
which has good notification capabilities:




Hi, yes, that sounds pretty awesome!!!

The SystemD thing that Debbie sent me involves making service files that 
then get referenced by other unit files and that get a parameter that 
you can use to customize the script or output of your program.


I have been polling stuff too and I think it is a good system but then I 
am usually not running as a daemon.


Monit sounds like a very good solution.

I'll have a look some time, thank you.


Monit works by polling service states periodically, so some delay is
always involved. Monit can, however, do whatever you want when a 
problem

is encountered and is not limited to just restarting the service.

Combining systemd instantaneous restarts with monit's notifications is 
a

pretty good system imho.


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] automatically restart openvpn

[Xen]

David Sommerseth schreef op 31-05-2017 18:28:

On 31/05/17 17:05, Xen wrote:

Riccardo Paolo Bestetti schreef op 31-05-2017 16:01:

It's not OpenVPN you should configure, but your Operating System.
You should refer to its documentation or its relevant mailing list.


You can also do:

# crontab -l | { cat; echo "*/15 * * * * /bin/sh -c 'ifconfig | grep
tun0 > /dev/null || systemctl restart openvn'"; } | crontab

This will check very 15 minutes whether tun0 is up and if not will use
systemctl to restart openvpn service.

Not sure what runs on Raspbian.


As you use systemctl, that implies systemd.  Then that hack is truly
ugly compared to what systemd provides.


So how can you get systemd to send you emails?

Can you let it run a script on restart?

Regards.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] automatically restart openvpn

[Xen]

Riccardo Paolo Bestetti schreef op 31-05-2017 16:01:

It's not OpenVPN you should configure, but your Operating System.
You should refer to its documentation or its relevant mailing list.


You can also do:

# crontab -l | { cat; echo "*/15 * * * * /bin/sh -c 'ifconfig | grep 
tun0 > /dev/null || systemctl restart openvn'"; } | crontab


This will check very 15 minutes whether tun0 is up and if not will use 
systemctl to restart openvpn service.


Not sure what runs on Raspbian.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] learn address script

[Xen]

Gert Doering schreef op 28-05-2017 16:29:

Hi,

On Sun, May 28, 2017 at 11:46:43AM +0200, Xen wrote:

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


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] learn address script

[Xen]

Jan Just Keijser schreef op 27-05-2017 22:48:


if all external hosts can reach the server but you (internal host? vpn
server?) then it's - as always - a routing or NATting issue.

This _IS_ covered in a recipe of my OpenVPN cookbook





I mean a mail log for myself from this morning shows first from the 
server that the client disconnected at 10:18, then the cron job at the 
client notifying me that tun0 was down, at 10:32, then one minute later 
at 10:33 from the server that the client is reconnecting ;-).


System works like a charm ;-).

This is the last message before disconnect:

May 28 10:17:08 perfection ovpn-synology[29139]: [Diskstation] 
Inactivity timeout (--ping-restart), restarting
May 28 10:17:08 perfection ovpn-synology[29139]: /sbin/ip addr del dev 
tun0 local 10.8.20.25 peer 10.8.20.5
May 28 10:17:08 perfection ovpn-synology[29139]: 
SIGUSR1[soft,ping-restart] received, process restarting
May 28 10:17:10 perfection ovpn-synology[29139]: UDPv4 link local 
(bound): [undef]
May 28 10:17:10 perfection ovpn-synology[29139]: UDPv4 link remote: 
[AF_INET]92.109.167.182:1194
May 28 10:17:29 perfection ovpn-synology[29139]: [Diskstation] Peer 
Connection Initiated with [AF_INET]92.109.167.182:1194
May 28 10:17:31 perfection ovpn-synology[29139]: AUTH: Received control 
message: AUTH_FAILED
May 28 10:17:31 perfection ovpn-synology[29139]: 
SIGTERM[soft,auth-failure] received, process exiting


At that point the link had been up for 2 days straight.

After restart it again establishes an UDP connection.

So my link is apparently down for a few minutes, it tries one 
ping-restart, fails to auth, and then stops trying.


Does connect-retry-max also apply to these things?

But it does not apply to UDP? So I think it should not have any bearing 
on reconnects?


I can find no setting detailing any restart number or options.

Actually there does seem to be a problem on the server...



Sun May 28 10:18:25 2017 RADIUS-PLUGIN: FOREGROUND THREAD: 
isAuthenticated()1Sun May 28 10:18:25 2017 RADIUS-PLUGIN: FOREGROUND 
THREAD: isAcct()1Sun May 28 10:18:26 2017 RADIUS-PLUGIN: Got no response 
from radius server.
Sun May 28 10:18:26 2017 RADIUS-PLUGIN: FOREGROUND THREAD: Error ar 
rekeying!
Sun May 28 10:18:26 2017 RADIUS-PLUGIN: BACKGROUND-ACCT: Statusfile  
could not opened.
Sun May 28 10:18:26 2017 Error: RADIUS-PLUGIN: BACKGROUND  AUTH: Auth 
failed!.




But I don't know, it was just a temporary glitch.

But the temporary glitch caused the connection to be dropped...

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] learn address script

[Xen]

Jan Just Keijser schreef op 27-05-2017 22:48:


On 23/05/17 00:25, Xen wrote:



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.

This _IS_ covered in a recipe of my OpenVPN cookbook



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.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] learn address script

[Xen]

Gert Doering schreef op 22-05-2017 19:03:

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

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

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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

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

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Openvpn-users] client connect script preventing openvpn restart

[Xen]

Hi,

I have an older Synology installation of openvpn (server). There is some 
shell script starting openvpn. I am using a client connect script in the 
config. Sometimes I find that the server won't restart when I tell it to 
(it first sends regular kill messages then if that does not work I send 
kill -9), and then I find that the client connect script has actually 
been hanging.

That is very weird because it only tries to send an email message using 
some PHP script. Of course that could stall.

The status code for the process was "S" which means interruptable sleep.

I was just wondering if anyone ever "battled" with something like this 
and what a good solution would be.

I can:
- kill any client scripts in my restart script
- always run the PHP email script in some background process to ensure 
it doesn't hang the main process.

I just want to not have to look at these problem cases anymore lol.

I guess I should just background the thing?

Regards.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users