Score:0

OCServ dropping connections (OCServ 0.12.6 on Ubuntu 20.04.03)

in flag

Server: OCServ

ocserv 0.12.6

Compiled with: seccomp, tcp-wrappers, oath, radius, gssapi, PAM, PKCS#11, AnyConnect
GnuTLS version: 3.6.13 (compiled with 3.6.11)

Client: openconnect

OpenConnect version v8.10-2build1~ubuntu20.04.1~ppa1
Using GnuTLS 3.6.13. Features present: TPMv2, PKCS#11, RSA software token, HOTP software token, TOTP software token, Yubikey OATH, System keys, DTLS, ESP
Supported protocols: anyconnect (default), nc, gp, pulse

Network diagram

                   VPS BOX                                                                 
                |---------------------------------------------|  
                |              others *< ----+                                              |  
                |                            |      vpn.<domain>.com rev proxy pass-thru to |  
                |                |------@HA Proxy -----------|  127.0.1.1:443               |  
                |                |                           | (SSL handled by ocserv)      |  
                |               [TCP 80 & TCP 443]           |                              |  
inet --> public IP - > 10.10.0.5                             |---> 127.0.1.1                |  
                |         [udp 44443]                               [tcp 443]               |  
                |          \                                         |                      |  
                |           \                                        @                      |  
                |            \-------------------------------------=@ocserv listening on    |  
                |                                 tcp 127.0.1.1:443 & udp 10.10.0.5:44443   |  
                |---------------------------------------------|  

NOTE:

Effectively, what I am faced with is as below:

  • Am able to connect no problem
  • isolate-workers is set to false in the config
  • The udp-port in conf is set to 44443 (non-443) to rule out any VPS specific issues on that port
  • DTLS is established no problem
  • The server SSL cert is a wildcard cert.
  • libpam-cap has been disabled on the VPS box where the ocserv instance is running, to get around crash issue as noted here
  • The below noted issue is seen regardless of whether DTLS is established or not (I set the udp-listen-host address to the lo interface to ensure UDP packets recd on the public IP DO NOT make it to OCServ, thus DTLS is NOT established).
  • ISSUE Seemingly randomly, or maybe at some regular interval, the connection seems to get reset with openconnect reporting SSL read error: The TLS connection was non-properly terminated.; reconnecting. (line number 191 of log file openconnectout_20211108.log). OCServ on the server end seems to report the error as below (full verbose logs attached for both openconnect and ocserv). Just prior to this error surfacing, the openconnect client logs show multiple lines of Sent DTLS packet of 48 bytes; DTLS send returned 42\rNo work to do; sleeping for 27000 ms... indicating DTLS packets are being communicated. The same info can be seen in the ocserv logs as well. The ocserv logs below can be see in line number 589 of log file ocservout_20211108.log
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> received 42 byte(s) (DTLS)
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> decompressed 41 to 48
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> writing 48 byte(s) to TUN
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:696
ocserv[<first_worker_pid>]: TLS[<5>]: REC: Sending Alert[1|0] - Close notify
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Preparing Packet Alert(21) with length: 2 and min pad: 0
ocserv[<first_worker_pid>]: TLS[<9>]: ENC[0x55f94ae54b60]: cipher: AES-256-GCM, MAC: AEAD, Epoch: 2
ocserv[<first_worker_pid>]: TLS[<2>]: WRITE: -1 returned from 0x9, errno: 32
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[errno_to_gerr]:230
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:722
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/record.c[_gnutls_send_tlen_int]:588
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/record.c[gnutls_bye]:304
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Start of epoch cleanup
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: End of epoch cleanup
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae54b60]: Epoch #2 freed
ocserv[<first_worker_pid>]: TLS[<3>]: ASSERT: ../../lib/buffers.c[_gnutls_io_write_flush]:696
ocserv[<first_worker_pid>]: TLS[<5>]: REC: Sending Alert[1|0] - Close notify
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Preparing Packet Alert(21) with length: 2 and min pad: 0
ocserv[<first_worker_pid>]: TLS[<9>]: ENC[0x55f94ae46800]: cipher: AES-256-GCM, MAC: AEAD, Epoch: 1
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Sent Packet[281474976710664] Alert(21) in epoch 1 and length: 39
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Start of epoch cleanup
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: End of epoch cleanup
ocserv[<first_worker_pid>]: TLS[<5>]: REC[0x55f94ae46800]: Epoch #1 freed
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> sending message 'sm: worker cli stats' to secmod
ocserv[<secmod_pid>]: sec-mod: received request from pid <first_worker_pid> and uid 65534
ocserv[<secmod_pid>]: sec-mod: cmd [size=73] sm: worker cli stats
ocserv[<first_worker_pid>]: worker[<username>]: <vpn_client_public_ip_address> sent periodic stats (in: 192, out: 496) to sec-mod
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 worker terminated
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 sending msg sm: session close to sec-mod
ocserv[<secmod_pid>]: sec-mod: received request sm: session close
ocserv[<secmod_pid>]: sec-mod: cmd [size=40] sm: session close
ocserv[<secmod_pid>]: sec-mod: temporarily closing session for <username> (session: <session_ID>)
ocserv[<ocserv_main_pid>]: main[<username>]:<vpn_client_public_ip_address>:47586 user disconnected (reason: unspecified error, rx: 192, tx: 496)
  • The 4th line in above extract (line 592 of log file ocservout_20211108.log) is where the issue seems to stem at.
  • INFO: Around line 887 of log file ocservout_20211108.log, ignore messages around client prematurely closing connection as that was just me killing openconnect on the client machine.
  • Similar issues were seen when using the OpenConnect GUI for Windows, as well as the OpenConnect android app.

Are there any recommendations on how to get around this? I'd like to avoid the VPN connection going on and off frequently.

ocservout_20211108.log (obtained by doing a sudo ocserve -f -c /etc/ocserv/ocserv.conf -d 9999 > outfile.log 2>&1)

openconnectout_20211108.log (obtained by doing a echo -n obfuscated_password | sudo openconnect -b vpn.<domain>.com:443 -u obfuscated_username --passwd-on-stdin -vvv --dump-http-traffic > outfile.log 2>&1 )

NOTE Sensitive info from above log files has been REDACTED/OBFUSCATED

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.