Confirmed. This is a core 88 updated to core 89. Changing 
status /var/log/ovpnserver.log 30 
to 
status /var/run/ovpnserver.log 30
and restarting the openvpn server works.

Also, just stopping and starting the net-to-net vpn's made the net-to-net statistics working.

Met vriendelijke groet,
With kind regards,

Jacques Hylkema
ICT Manager
Tel +31 (0)342-407040
E-mail j.hylkema@intronics.nl
LinkedIn
Email
Website

Intronics
Member of the TKH-group
Intronics b.v.
Postbus 123, 3770 AC
Koolhovenstraat 1E
3772 MT  Barneveld
Computer Connectivity
Industrial Connectivity
Audio/Video
Retail
Tel. +31 (0)342-407040
Tel. +31 (0)342-407080
Tel. +31 (0)342-407001
Tel. +31 (0)46-4269000
Fax +31 (0)342-412114
sales@intronics.nl
www.intronics.nl

Disclaimer:
This message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and delete this message from your system. Any unauthorised use or dissemination of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. Intronics b.v. shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system. Intronics b.v. does not guarantee that the integrity of this communication has been maintained nor that this communication is free of viruses, interceptions or interference.

PPlease consider the environment before printing this e-mail




2015-04-22 13:23 GMT+02:00 Alexander Marx <alexander.marx@oab.de>:
Hi

please check your /var/ipfire/ovpn/server.conf file.

if you have the lines:

status-version 1
status /var/log/ovpnserver.log 30

change them to

status-version 1
status /var/run/ovpnserver.log 30

and restart openvpn server. Does that help?

Alexander Marx

Fachinformatiker Systemintegration


Ostangler Brandgilde

Versicherungsverein auf Gegenseitigkeit



Flensburger Str. 5

24376 Kappeln

Tel.: (04642) 91 47 - 62

Fax: (04642) 91 47 - 823
Web: http://www.ostangler.de


Die Ostangler Brandgilde VVaG ist TÜV-Nord zertifiziert nach ISO 9001:2008
Aufsichtsratvorsitzender: Hans-Walter Jens

Vorstandsvorsitzender: Jens-Uwe Rohwer, Vorstand: Andreas Schmid
Amtsgericht Flensburg HRB-Nr.: 158 KA
USt-IdNr.: DE164624941
Am 22.04.2015 um 13:17 schrieb Mathias Schneuwly:

Hi guys


I can confirm this problem. I updated from core 88 to 89 and the statistics do not work. The permission is also different in my system:

-rw-r--r-- 1 root nobody 0 Apr 22 09:37 /var/run/ovpnserver.log


I changed the ownership to nobody.nobody but till now I don't have any data in it.


Restarting openvpn will change the ownership back to root.nobody...



It seems that openvpn does still write into /var/log/ovpnserver.log in my case. I also can't see the status of a openvpn roadwarrior in the gui. They are all marked as "Getrennt" event /var/log/ovpnserver.log says that two roadwarriors are connected.


My /var/ipfire/ovpn/server.conf looks like this:

#OpenVPN Server conf

daemon openvpnserver
writepid /var/run/openvpn.pid
#DAN prepare OpenVPN for listening on blue and orange
;local XXXXX
dev tun
proto udp
port 1194
script-security 3 system
ifconfig-pool-persist /var/ipfire/ovpn/ovpn-leases.db 3600
client-config-dir /var/ipfire/ovpn/ccd
tls-server
ca /var/ipfire/ovpn/ca/cacert.pem
cert /var/ipfire/ovpn/certs/servercert.pem
key /var/ipfire/ovpn/certs/serverkey.pem
dh /var/ipfire/ovpn/ca/dh1024.pem
server 10.138.84.0 255.255.255.0
tun-mtu 1500
route 10.138.85.0 255.255.255.0
route 10.138.86.0 255.255.255.0
client-to-client
mtu-disc yes
keepalive 10 60
status-version 1
status /var/log/ovpnserver.log 30
cipher BF-CBC
push "dhcp-option DOMAIN XXXXX"
push "dhcp-option DNS 192.168.2.1"
max-clients 100
tls-verify /usr/lib/openvpn/verify
crl-verify /var/ipfire/ovpn/crls/cacrl.pem
user nobody
group nobody
persist-key
persist-tun
verb 3


Regards

Mathias


-----Ursprüngliche Nachricht-----
Von: Alexander Marx <alexander.marx@oab.de>
Gesendet: Mit 22 April 2015 11:30
An: Michael Tremer <michael.tremer@ipfire.org>; Rod Rodolico <rodo@dailydata.net>
CC: development@lists.ipfire.org; Alexander Marx <alexander.marx@ipfire.org>
Betreff: Re: Core 89 bug?

I think this issue is related to the box tracking the testing branch.

When Rod reinstalls the box and issue remains, this could be a bug, but i just updtaed some of my boxes to core 89 (no testing branch) and all seems very well.
the ovpnserver.log (now under /var/run) has these permissions:

-rw-r--r--  1 nobody nobody    0 Apr 22 10:03 ovpnserver.log

Rod please report back after reinstalling.

Let me ping Alex about this...

It should be fine that the file is owned by root. It just has to be
readable by collectd and writeable by openvpn itself. The status of the
RW connections is checked over the telnet management interface of the
openvpn daemon.

-Michael

On Wed, 2015-04-22 at 03:13 -0500, Rod Rodolico wrote:
I was able to track it down to /var/run/ovpnserver.log having ownership
root:root, but permissions 600, for some reason. I did the update on
another router and it appears to have permissions set to 644, which is
more logical since apache needs to be able to read it.

My office router is set to always go into testing branch, so maybe
something happened there. I think I'll rebuild the router from scratch,
but if anyone else reports something similar, have them look at the
ownership of /var/run/ovpnserver.log.

Rod

On 04/21/2015 11:50 PM, Rod Rodolico wrote:
I have Core 89 installed on my router and just noticed something. When I
vpn in (OpenVPN, Road Warrior), it does not show up on the vpn list; the
entry on the web interface shows the user as disconnected.

Looking at /var/log/ovpnserver.log shows nothing also.

However, I am connected; I can ping a machine on the LAN.

I rebooted the firewall just to make sure I did not do anything weird,
but still no changes.

I see the login in /var/log/messages, and /var/log/ovpnserver.log shows
it was updated at the correct time, just no entries.

I have saved copies of the logs in question and have been able to
recreate the scenario.

Rod


_______________________________________________

Development mailing list

Development@lists.ipfire.org

http://lists.ipfire.org/mailman/listinfo/development



_______________________________________________
Development mailing list
Development@lists.ipfire.org
http://lists.ipfire.org/mailman/listinfo/development


_______________________________________________
Development mailing list
Development@lists.ipfire.org
http://lists.ipfire.org/mailman/listinfo/development