Ovpn n2n reconnect fails after update core139

digger · 13 January 2020 18:43

Hi dear forum members,

ovpn n2n fails to reconnect after scheduled dsl interruption. Only an reboot brings connection up again.
Any suggestion, how to solve that behaviour?

best

digger

pike_it · 14 January 2020 14:21

More info about the settings of this n2n tunnel?

digger · 14 January 2020 16:57

Hi Pike,

the following configs are used:

IPFire n2n Open VPN Server Config by ummeegge und m.a.d

User Security

user nobody

group nobody

persist-tun

persist-key

script-security 2

IP/DNS for remote Server Gateway

remote 5678.org

float

IP adresses of the VPN Subnet

ifconfig 10.85.253.1 10.85.253.2

Client Gateway Network

route 192.168.5.0 255.255.255.0

up “/etc/init.d/static-routes start”

tun Device

dev tun

#Logfile for statistics

status-version 1

status /var/run/openvpn/test-n2n 10

Port and Protokol

port 11194

proto tcp-server

Packet size

tun-mtu 1400

Auth. Server

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

Cipher

cipher AES-256-CBC

HMAC algorithm

auth SHA512

Debug Level

verb 3

Tunnel check

keepalive 10 60

Start as daemon

daemon testn2n

writepid /var/run/testn2n.pid

Activate Management Interface and Port

management localhost 11194

Client:

IPFire n2n Open VPN Client Config by ummeegge und m.a.d

User Security

user nobody

group nobody

persist-tun

persist-key

script-security 2

IP/DNS for remote Server Gateway

remote 1234.org

float

IP adresses of the VPN Subnet

ifconfig 10.85.253.2 10.85.253.1

Server Gateway Network

route 192.168.0.0 255.255.255.0

tun Device

dev tun

#Logfile for statistics

status-version 1

status /var/run/openvpn/-n2n 10

Port and Protokoll

port 11194

proto tcp-client

Packet size

tun-mtu 1400

remote-cert-tls server

Auth. Client

tls-client

Cipher

cipher AES-256-CBC

pkcs12 /var/ipfire/ovpn/certs/test.p12

HMAC algorithm

auth SHA512

Debug Level

verb 3

Tunnel check

keepalive 10 180

Start as daemon

daemon testn2n

writepid /var/run/test.pid

Activate Management Interface and Port

management localhost 11194

remsub 192.168.5.0/255.255.255.0

Logfile

status-version 1

status /var/run/openvpn/test-n2n 10

Best
digger

tikok974 · 28 January 2020 15:00

Hi everybody,

I think i’ve a similar problem

I just tried to set up a VPN between 2 sites that has 2 Ipfire firewalls and the connection is not done on the “Client” site. Indeed, on the “Server” site, Ipfire displays the status “Connected” while on the “Client” site, OpenVPN displays the status “Disconnected”!
However, I imported the “zip” configuration file of the client. I don’t have any error displayed in the logs!
I’m also on the core version 139 (I didn’t try on the previous versions).

Is there a way to find out what is blocking (command line execution of the n2n connection to check step by step) ?

Many thanks

ummeegge · 28 January 2020 15:42

Hi all,
@digger
can you check the logs in verb 4 what happens after an reconnect and post it here ? Or is there somewhere ping and ping-restart findable ?

@tikok974
may we have here two different problems since digger can connect but the reconnect fails for him. Since there is not always an error needed for a not established connection it might be helpful if you post also your logs too ?

Best,

Erik

tikok974 · 29 January 2020 10:05

Hi everybody,

You can find here my n2n client config:

[root@myipfire]# grep -E -v '^(#|;|$|[ ]*#)' /var/ipfire/ovpn/n2nconf/LinkVD/LinkVD.conf 
user nobody
group nobody
persist-tun
persist-key
script-security 2
remote vpn.mydomain.com
float
ifconfig 10.200.17.2 10.200.17.1
route 172.12.14.0 255.255.254.0
up "/etc/init.d/static-routes start"
dev tun
status-version 1
status /var/run/openvpn/LinkVD-n2n 10
port 11207
proto udp
tun-mtu 1500
fragment 1300
mssfix
remote-cert-tls server
tls-client
cipher AES-256-CBC
pkcs12 /var/ipfire/ovpn/certs/LinkVD.p12
auth SHA512
verb 4
keepalive 10 60
daemon LinkVDn2n
writepid /var/run/LinkVDn2n.pid
management localhost 11207
[root@myipfire]#

I set the log setting to 4 manually in the file “/var/ipfire/ovpn/n2nconf/myclient/myclient.conf”
I have no log in “/var/log/openvpn” !
The only thing I see in the “/var/log/messages” is this:

Jan 29 11:00:56 myipfire collectd[8535]: Exiting normally.
Jan 29 11:00:56 myipfire collectd[8535]: collectd: Stopping 1 read threads.
Jan 29 11:00:56 myipfire collectd[8535]: ping plugin: Shutting down thread.
Jan 29 11:00:56 myipfire collectd[8535]: rrdtool plugin: Shutting down the queue thread. This may take a while.
Jan 29 11:00:58 myipfire collectd[8775]: openvpn plugin: Unable to read "/var/run/openvpn/LinkVD-n2n": No such file or directory
Jan 29 11:00:58 myipfire collectd[8776]: cpufreq plugin: Found 4 CPUs
Jan 29 11:00:58 myipfire collectd[8776]: Initialization complete, entering read-loop.
Jan 29 11:00:58 myipfire collectd[8776]: ping plugin: ping_host_add (gateway) failed: getaddrinfo: Name or service not known
Jan 29 11:00:58 myipfire collectd[8776]: ping plugin: No host could be added to ping object. Giving up.
Jan 29 11:00:58 myipfire collectd[8776]: openvpn plugin: fopen(/var/run/openvpn/LinkVD-n2n) failed: No such file or directory
Jan 29 11:00:58 myipfire collectd[8776]: ping plugin: The ping thread had a problem. Restarting it.
Jan 29 11:00:58 myipfire collectd[8776]: read-function of plugin `ping' failed. Will suspend it for 60 seconds.
Jan 29 11:00:58 myipfire collectd[8776]: ping plugin: ping_host_add (gateway) failed: getaddrinfo: Name or service not known
Jan 29 11:00:58 myipfire collectd[8776]: ping plugin: No host could be added to ping object. Giving up.

also, I specify that my connection to the Internet is via PPPOE.

Many thanks

ummeegge · 29 January 2020 13:50

You can try an
grep 'n2n' /var/log/messages
for already existing log entries,

or for an live overview if you start the connection
tailf /var/log/messages | grep ‘n2n’
which should work on both sides.

Best,

Erik

EDIT: You should mask personal informations then

digger · 29 January 2020 15:05

Hi ummeegge,

thank you for your support.

I’m very busy at the moment but I just configured verb 4 at both sides.

I will post the results to you.

Please stay a little patient.

Btw, what#s about the sslh with setcap enabled, have you done a new compilation?

Best

Digger

ummeegge · 29 January 2020 16:22

No problem take the time you need .
OT: Regarding to the sslh topic i did only that one --> https://patchwork.ipfire.org/patch/2250/ until now.

Best,

Erik

digger · 2 February 2020 12:34

Hi ummeegge,

here are the logs from 30.01.20.
Logs.zip (19.4 KB)
There is as a workaround a reboot about 05.00 am.

Best Digger

ummeegge · 2 February 2020 15:59

Hi,
there seems to be something messed up with your logs -->

…
6e67 4e61 6d65 5e57 6562 5265 736f 7572
6365 5552 4c5f 1014 5765 6252 6573 6f75
7263 6546 7261 6d65 4e61 6d65 5f10 0f57
6562 5265 736f 7572 6365 4461 7461 5f10
1357 6562 5265 736f 7572 6365 4d49 4d45
5479 7065 5575 7466 2d38 5f10 1266 696c
653a 2f2f 2f69 6e64 6578 2e68 746d 6c50
4f12 0001 efe8 3c21 444f 4354 5950 4520
6874 6d6c 2050 5542 4c49 4320 222d 2f2f
5733 432f 2f44 5444 2048 544d 4c20 342e
3031 2f2f 454e 2220 2268 7474 703a 2f2f
7777 772e 7733 2e6f 7267 2f54 522f 6874
6d6c 342f 7374 7269 6374 2e64 7464 223e
…

Best,

Erik

digger · 2 February 2020 17:08

Hi Erik,

do not understand the numbers above.
Where do they come from?
Looks like HEX.
Give it a second try.
Log.zip (19.3 KB)

Best
Digger

ummeegge · 2 February 2020 17:45

Same result,
did you checked it too ? May a discourse problem ? You can also post it may here if this does not work. May a .txt can also be a way ?

Best,

Erik

digger · 2 February 2020 18:56

Hi Erik,

upload as *.txt isn’t possible. Files edited by a mac.
A conversion has been automatically done without being noticed by me. Sorry!

I’ve converted by hand.
3rd try.
Clientn2n.zip (8.7 KB) Servern2n.zip (7.4 KB)

Hope it will work for you.

Best
Digger

ummeegge · 3 February 2020 11:24

Hi Digger,
got it now. OK, in your client log appears
failed: Cannot assign requested address
. If you are sure that no other service are listening on port 11194 TCP, It looks like N2N does not close the socket and is waiting from packages from the old IP.
Currently not really sure what´s happening there.
You can try it may with something like this

#!/bin/bash -

# Enter here your green0 remote IP
GREENREMOTEIP="192.168.?.?"


if ! ping -c 20 ${GREENREMOTEIP}; then
   # restart N2N if remote side is not reachable
   /usr/local/bin/openvpnctrl -kn2n
   sleep 10
   /usr/local/bin/openvpnctrl -sn2n
fi

exit 0

# EOF

to check the remote side cyclic every e.g. 10 minutes or so via fcrontab if this works.

The other problem:
Failed to extract curve from certificate (UNDEF), using secp384r1 instead
seems indeed a 2.4.8 problem. Have found this ticket --> https://community.openvpn.net/openvpn/ticket/1228?cversion=0&cnum_hist=21 . May the communication get there a little better and OpenVPN checks for a possible bug on their side again…

For the first some ideas,

Best,

Erik

digger · 3 February 2020 16:47

Hi Erik,

my first solution works like your script.
But killing the process doesn’t solve the problem. I’ve to restart the entire firewall.
Curiously after a fresh install, I only had to kill and restart openvpn at the client. After update to core 139, I have to reboot the server. This procedure is known from previously installation. I agree, the port stays open. Another mechanism to close and reopen the port would be appreciated.

Thanks for investigating that behaviour.

Best
Thomas

ummeegge · 3 February 2020 17:00

Hi Thomas,
am i right that the script solution worked before have had that in memory ? If yes until when works it ?

Best,

Erik

EDIT(s): (Sorry have currently no testing possibilities)

Can you may try to comment --persist-tun in client.conf
;persist-tun
for a further testing ?
According to the “Failed to extract curve from certificate (UNDEF), using secp384r1 instead.” , can you may open up a new topic to reference to. Will give the OpenVPN Tracker some feedback then. Needed info for this, OpenVPN building with version and configure options which should include the OpenSSL version, from client and server (can be done with a ‘openvpn --version’) and a log portion of both

digger · 3 February 2020 18:13

Hi Erik,

it’s a long time ago. I was in doubt, whether the sslh process interfered with that. I investigated that, but no change, when sslh was disabled. I’m using ipfire over years, connecting two networks without any problems. Suddenly after an update shit happens. This was one of the reasons to change hardware and installing the 64bit edition. But …

Disabling “persist-tun” I’ve tested before, no success.
I think it’s a problem of the server.

Thanks for advice, I will post that OpenVPN question at weekend.

Meanwhile I’m hoping, that wireguard will find it’s way into this project.

Best

Thomas

tikok974 · 4 February 2020 08:36

Hi everybody,

As for me, my problem was solved after a full reboot of Ipfire. I hadn’t reboot yet after the VPN server setup and other modifications I made on my installation.

Many thanks

ummeegge · 31 March 2020 16:15

Hi all,
there is a fix for the “Failed to extract curve from certificate (UNDEF) using secp384r1 instead.” problem --> https://community.openvpn.net/openvpn/ticket/1228 am building the current DEV version including the branch from Arne Schwabe and will give it a try if there is time for this.

If someone is interested too, feedback might be great.

Best,

Erik