Openvpn connection lost at 64mins

Support
,
1

**NethServer Version: 7.9.2009
**Module:openvpn
Connecting a remote voip phone the LAN. it works well until 64 mins and then drops. Reboot the phone to reconnect. So far have not found the code with the stopwatch!!
`Sat Jul 8 14:06:00 2023 ext522@xyz.com/client:36759
SENT CONTROL [ext522@xyz.com]:
‘PUSH_REPLY,
dhcp-option DOMAIN xyz.com,dhcp-option DNS server,dhcp-option WINS server,dhcp-option NBDD
server,dhcp-option NBT 2,route-gateway server,ping 20,ping-restart 120,ifconfig clientip 255.255.255.0,peer-id 1,cipher AES-256-GCM’ (status=1)
Sat Jul 8 14:06:00 2023 ext522@xyz.com/client:36759 Data Channel: using negotiated cipher ‘AES-256-GCM’

Sat Jul 8 14:06:00 2023 ext522@xyz.com/client:36759 Outgoing Data Channel: Cipher ‘AES-256-GCM’ initialized with 256 bit key

Sat Jul 8 14:06:00 2023 ext522@xyz.com/client:36759 Incoming Data Channel: Cipher ‘AES-256-GCM’ initialized with 256 bit key

Sat Jul 8 14:06:01 2023 ext522@xyz.com/client:36759 MULTI: Learn: c6:3b:71:f2:68:9a → ext522@xyz.com/client:36759
Sat Jul 8 14:32:17 2023 MANAGEMENT: Client connected from /var/spool/openvpn/host-to-net

Sat Jul 8 14:32:17 2023 MANAGEMENT: CMD ‘status 3’

Sat Jul 8 14:32:17 2023 MANAGEMENT: Client disconnected

Sat Jul 8 14:33:13 2023 MANAGEMENT: Client connected from /var/spool/openvpn/host-to-net

Sat Jul 8 14:33:13 2023 MANAGEMENT: CMD ‘status 3’

Sat Jul 8 14:33:13 2023 MANAGEMENT: Client disconnected

Sat Jul 8 14:33:13 2023 MANAGEMENT: Client connected from /var/spool/openvpn/host-to-net

Sat Jul 8 14:33:13 2023 MANAGEMENT: CMD ‘status 3’

Sat Jul 8 14:33:13 2023 MANAGEMENT: Client disconnected

Sat Jul 8 14:33:13 2023 MANAGEMENT: Client connected from /var/spool/openvpn/host-to-net

Sat Jul 8 14:33:13 2023 MANAGEMENT: CMD ‘status 3’

Sat Jul 8 14:33:13 2023 MANAGEMENT: Client disconnected

Sat Jul 8 14:33:58 2023 MANAGEMENT: Client connected from /var/spool/openvpn/host-to-net

Sat Jul 8 14:33:58 2023 MANAGEMENT: CMD ‘status 3’

Sat Jul 8 14:33:58 2023 MANAGEMENT: Client disconnected

Sat Jul 8 14:38:49 2023 167.94.138.49:42280 TLS: Initial packet from [AF_INET]167.94.138.49:42280 (via [AF_INET]192.168.15.2%eth0), sid=b668660f eb05900e
Sat Jul 8 14:38:51 2023 read UDPv4 [CMSG=8|ECONNREFUSED]: Connection refused (code=111)
Sat Jul 8 14:38:55 2023 read UDPv4 [CMSG=8|ECONNREFUSED]: Connection refused (code=111)
Sat Jul 8 14:39:03 2023 read UDPv4 [CMSG=8|ECONNREFUSED]: Connection refused (code=111)
Sat Jul 8 14:39:19 2023 read UDPv4 [CMSG=8|ECONNREFUSED]: Connection refused (code=111)

Sat Jul 8 14:39:49 2023 167.94.138.49:42280 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

Sat Jul 8 14:39:49 2023 167.94.138.49:42280 TLS Error: TLS handshake failed

Sat Jul 8 14:39:49 2023 167.94.138.49:42280 SIGUSR1[soft,tls-error] received, client-instance restarting`

Last connection
“08 Jul 2023, 14:05 08 Jul 2023, 15:09 01h 04m 00s”

The error lines are for ip 167.94.138.49 which is a Censys search engine spider. Could it be upsetting the VPN? Or does someone know of a 64 min timer?

2

A list of connections. It has to be a timer somewhere as it is consistent.

08 Jul 2023, 14:05 08 Jul 2023, 15:09 01h 04m 00s
08 Jul 2023, 11:23 08 Jul 2023, 12:27 01h 04m 00s
07 Jul 2023, 18:00 07 Jul 2023, 19:04 01h 04m 00s
07 Jul 2023, 16:10 07 Jul 2023, 17:14 01h 03m 59s
07 Jul 2023, 14:51 07 Jul 2023, 15:55 01h 03m 59s
07 Jul 2023, 13:19 07 Jul 2023, 14:23 01h 04m 00s
07 Jul 2023, 11:55 07 Jul 2023, 12:59 01h 04m 00s
3

Hi

Looks to me as if it’s a client issue. You say nothing what sort of client, only SIP VoIP phone.

Check your VoIP phone for the stopwatch, the logs say it’s being closed from the client side.

If all other OpenVPN clients using your server don’t have an issue, it’s a client issue!
And without information no one can help you.

Even with information, a VoIP phone isn’t running NethServer, so why should anyone help with a such exotic setup? VoIP phones usually are commercial and come with (paid) support…

My 2 cents
Andy

4

Thanks Andy
Appreciate the reply.
I just ran a VPN from a desktop and the Yealink T58 phone and only the phone dropped at 1 hr and 4 mins. So will push it to Yealink.
Just as an aside, it is 64 mins (ie) a factor of 2 so it has to be a setting somewhere or firmware bug.

5

Hi @compsos

It could also be RAM or other hardware, as a VoIP phonne isn’t designed for such Apps…

Yealink has good phones.

My 2 cents
Andy

6

Hi @Andy_Wismer
Looking in some Yealink docs this looks a likely candidate
This is openvpn info
“–reneg-sec n
Renegotiate data channel key after n seconds (default=3600).”

When using dual-factor authentication, note that this default value may cause the end user to be challenged to reauthorize once per hour.
Yealink have a reference/suggested setting of “reneg-sec 604800” But that is 168 hrs. Would the actual setting appear in a tcpdump file?

7

86400 (one daay) would probably be better…

9

Hi @Andy_Wismer
Well the reneg-sec for 168 hours gave us an extra 1 sec!
10 Jul 2023, 11:33 10 Jul 2023, 12:37 01h 04m 01s
So it is not the cause. Never had an issue with Yealink and VPN in the past beyond the vpn.cnf options.

10

Maybe an update changed stuff in the background, breaking things. Maybe you’ll find more info on the yealink forum?

11

Hi @Andy_Wismer
We found it and it was not the phone or the VPN, but a PBX setting for the extension to be remote. Turned it back to local and all good so far in testing. Thanks for the help.

1 Like
12

Was not the full answer. We modified the vpn.cnf file for the phone with
auth-nocache
tls-client

persist-tun

reneg-sec 0
reneg-bytes 1073741824
And now it stays up more than 12 hrs. It will be deployed next week so wait to see the mod proven in operation.

1 Like