public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Rod Rodolico <rodo@dailydata.net>
To: development@lists.ipfire.org
Subject: Re: Core 89 bug?
Date: Thu, 23 Apr 2015 02:00:16 -0500	[thread overview]
Message-ID: <55389880.2040607@dailydata.net> (raw)
In-Reply-To: <CAFHX57eSk0pWkxeUQTrt0wJiJ-mwX+kBUZn+RkDPMc-Mn8_7qw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 10565 bytes --]

I'm sorry, but I sent this to an individual, not  the list.

Just another report. On a different router, I did an upgrade from 87 to
89 or it may have been 88 to 89. Not sure. It had not been updated since
January, I believe.

On that machine, the stats are being written to /var/log/ovpnserver.log.

After the upgrade, I did restart the router.

Another difference between the two firewalls (the one at the office
which is the testing one and the pure production one I am describing
here). I'll call them testing and production.

Testing has menu options OpenVPN Client and OpenVPN Server under status.

Production has menu options "OpenVPN Road Warrior Statistics" and
OpenVPN Net-to-Net Statistics".

Both are now sitting at Core Update 89.

I have not updated any other routers at this point, though I think I can
safely do it.

Instead of replacing the testing router at this time, I'm going to build
out a router that I am preparing for deployment, so I'll do a clean
install on it. It will have a Site-to-Site connection on it. I'll
probably build a RoadWarrior on it just for fun.

Rod

On 04/23/2015 01:08 AM, Jacques Hylkema wrote:
> 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(a)intronics.nl <mailto:j.hylkema(a)intronics.nl>	
> <http://www.linkedin.com/company/intronics>	LinkedIn
> <http://www.linkedin.com/company/intronics>
> 
> <mailto:sales(a)intronics.nl>	Email <mailto:sales(a)intronics.nl>
> 
> <http://www.intronics.nl/>	Website <http://www.intronics.nl/>
> 
> 
> 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(a)intronics.nl <mailto:sales(a)intronics.nl>
> www.intronics.nl <http://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.
> 
> 
> P	Please consider the environment before printing this e-mail
> 
> 
> 	
> 
> 
> 2015-04-22 13:23 GMT+02:00 Alexander Marx <alexander.marx(a)oab.de
> <mailto:alexander.marx(a)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(a)oab.de>
>>         <mailto:alexander.marx(a)oab.de>
>>         *Gesendet:* Mit 22 April 2015 11:30
>>         *An:* Michael Tremer <michael.tremer(a)ipfire.org>
>>         <mailto:michael.tremer(a)ipfire.org>; Rod Rodolico
>>         <rodo(a)dailydata.net> <mailto:rodo(a)dailydata.net>
>>         *CC:* development(a)lists.ipfire.org
>>         <mailto:development(a)lists.ipfire.org>; Alexander Marx
>>         <alexander.marx(a)ipfire.org> <mailto:alexander.marx(a)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(a)lists.ipfire.org <mailto:Development(a)lists.ipfire.org>
>>
>>         http://lists.ipfire.org/mailman/listinfo/development
>>
>>
>>
>>     _______________________________________________
>>     Development mailing list
>>     Development(a)lists.ipfire.org <mailto:Development(a)lists.ipfire.org>
>>     http://lists.ipfire.org/mailman/listinfo/development
> 
> 
>     _______________________________________________
>     Development mailing list
>     Development(a)lists.ipfire.org <mailto:Development(a)lists.ipfire.org>
>     http://lists.ipfire.org/mailman/listinfo/development
> 
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development(a)lists.ipfire.org
> http://lists.ipfire.org/mailman/listinfo/development
> 

-- 
Rod Rodolico
Daily Data, Inc.
POB 140465
Dallas TX 75214-0465
214.827.2170
http://www.dailydata.net

       reply	other threads:[~2015-04-23  7:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAFHX57eSk0pWkxeUQTrt0wJiJ-mwX+kBUZn+RkDPMc-Mn8_7qw@mail.gmail.com>
2015-04-23  7:00 ` Rod Rodolico [this message]
2015-04-23  7:16 ` Rod Rodolico
2015-04-25  0:55   ` Rod Rodolico
2015-04-22  4:50 Rod Rodolico
2015-04-22  8:13 ` Rod Rodolico
2015-04-22  9:22   ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55389880.2040607@dailydata.net \
    --to=rodo@dailydata.net \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox