Connection issue with OpenVPN manager on raspberry pi 3

jokercomic12

I have configured OpenVPN manager on KODI.
It is not connecting. PIA VPN app works on UDP 53 on my pc,
Is it possible connect using OpenVPN in same port or Is there any other way?
Tried with different protocol filter UDP ,TCP, (UDP/TCP)  : Configuration screen similar in this link 

OpenVPN version:

OpenVPN 2.3.4 arm-unknown-linux

OpenVPN Log:

 [UNDEF] inactivity timeout (--ping-exit) exiting
SIGTERM [soft,ping-exit] received, process existing 

jokercomic12

trying use OpenVPN from pc

UDP link local: (not bound)
UDP link remote: [AF_INET]137.59.252.222:1198
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting
TCP/UDP: Preserving recently used remote address: [AF_INET]137.59.252.150:1198
UDP link local: (not bound)
UDP link remote: [AF_INET]137.59.252.150:1198
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting
TCP/UDP: Preserving recently used remote address: [AF_INET]137.59.252.176:1198
UDP link local: (not bound)
UDP link remote: [AF_INET]137.59.252.176:1198

jokercomic12

Change th port 53 and tried in pc for OpenVPN doesn't work.

WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting
TCP/UDP: Preserving recently used remote address: [AF_INET]137.59.252.211:53
UDP link local: (not bound)
UDP link remote: [AF_INET]137.59.252.211:53
VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: C=US, ST=OH, L=Columbus, O=Private Internet Access, CN=Private Internet Access CA, [email protected]
OpenSSL: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting
SIGTERM[hard,init_instance] received, process exiting

Max-P

The error you are getting when connecting to port 53 is because port 53 is one of our legacy ports, so you need to change the certificate and encryption settings to match. The error you are getting is telling you that OpenVPN is unable to verify the certificate (because you have the wrong one).

Try adjusting your settings to match those in this table: https://helpdesk.privateinternetaccess.com/hc/en-us/articles/225274288-Which-encryption-auth-settings-should-I-use-for-ports-on-your-gateways-

jokercomic12

Thanks Maz-P

After messing with config parameters. Made it work, seems working ok. I got following warning. Do I need to concern about this ?
Why it doesn't work with other port? Is it blocked by my ISP? I have checked with them. They said they don't block any any port.

WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This allows attacks like SWEET32.  Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
write UDP: Unknown error (code=10065)

Max-P

I don't know why it wouldn't work with other ports... Have you tried port 1194 or 8080 since it uses the same settings? If it doesn't work by changing only the port to either of the two, there is definitely something not quite right either on your ISP's side, or your router or possibly the Raspberry Pi itself if you have set a firewall that could be blocking those unwillingly.

As for the warnings, it's not optimal but we did mitigate the issue server-side by refreshing the key more often to reduce the risk. Of course it would be better to connect over one of the other ports with AES however...