I found out what was causing crazy OPENVPN entries in my log.

[Deleted member 27741]

I changed my webgui to https only and forgot to enter the port logging in. Then this happened in the log (ip address changed and truncated)-

Nov 18 21:22:22 openvpn[667]: TCP connection established with [AF_INET]xxx.xxx.x.x:52721
Nov 18 21:22:22 openvpn[667]: xxx.xxx.x.x:52721 TCP connection established with [AF_INET]xxx.xxx.x.x:52722
Nov 18 21:22:22 openvpn[667]: xxx.xxx.x.x:52721 WARNING: Bad encapsulated packet length from peer (32845), which must be > 0 and <= 1592 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Nov 18 21:22:22 openvpn[667]: xxx.xxx.x.x:52721 Connection reset, restarting [0]
Nov 18 21:22:22 openvpn[667]: xxx.xxx.x.x:52721 SIGUSR1[soft,connection-reset] received, client-instance restarting

Is this normal behavior? Maybe it depends on the port of the OPENVPN server (happens on 443 only)?
I think I just answered my own question. It only happens when I don't put a port in or enter port 443... one of the OPENVPN servers runs off port 443 so there you have it.

 

[netware5]

I changed my webgui to https only and forgot to enter the port logging in. Then this happened in the log (ip address changed and truncated)-

Nov 18 21:22:22 openvpn[667]: TCP connection established with [AF_INET]xxx.xxx.x.x:52721
Nov 18 21:22:22 openvpn[667]: xxx.xxx.x.x:52721 TCP connection established with [AF_INET]xxx.xxx.x.x:52722
Nov 18 21:22:22 openvpn[667]: xxx.xxx.x.x:52721 WARNING: Bad encapsulated packet length from peer (32845), which must be > 0 and <= 1592 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
Nov 18 21:22:22 openvpn[667]: xxx.xxx.x.x:52721 Connection reset, restarting [0]
Nov 18 21:22:22 openvpn[667]: xxx.xxx.x.x:52721 SIGUSR1[soft,connection-reset] received, client-instance restarting

Is this normal behavior? Maybe it depends on the port of the OPENVPN server (happens on 443 only)?
I think I just answered my own question. It only happens when I don't put a port in or enter port 443... one of the OPENVPN servers runs off port 443 so there you have it.

This is "normal" when using standard HTTP port 80 or HTTPS port 443 as OpenVPN listening port. This is because a lot of bots are probing on these ports and their failure to connect resulting in these entries in the log. If you move the OpenVPN server port to any other (not well known) port, these entries will disappear because of very low probability some bot to probe on not well known ports.

 

[Deleted member 27741]

I often connect from hotels and other places that have dodgy router setups. So I liked the idea of using port 443 because if the internet was up, then you would be guaranteed to be able to connect since that port was never blocked.

Do you think using another, not well known, port would be as reliable as having it on 443?

 

[netware5]

I often connect from hotels and other places that have dodgy router setups. So I liked the idea of using port 443 because if the internet was up, then you would be guaranteed to be able to connect since that port was never blocked.

Do you think using another, not well known, port would be as reliable as having it on 443?

I am in the same situation as you. I am a "road warrior" so I often connect from hotels, airports, etc. Due to the same reasons as you (restrictions of public Wi-Fi networks) I am using TCP ports 80 and 443 (I am running two OpenVPN servers on my router). So I just accept the inconvenience to have a lot connection attempts by bots. I have approximately 20 attempts per day in my log and just ignore them. This is the price I pay to be able to connect from any public network as the TCP ports 80 and 443 are always available in any network. So my advice to you is to continue using TCP port 443. Otherwise you may have problems in some networks that block the port you have chosen. The connection quality does not depend on the port chosen, just the ability to connect depends. Using the TCP ports 80 and 443 has one more advantage - if the public network is configured with HTTP proxy you will be able to connect.