Recently, a server of mine has been receiving lots of attempts to connect to it’s OpenVPN service. These attempts are from completely unknown hosts and do not end up establishing a valid connection. So, I’ve started blocking connections from these IP’s as some of them are actually generating a significant amount of traffic.
Strangely, 1.1.1.1 sometimes shows up as the source of a failed attempt to connect to my OpenVPN service. I can understand a compromised host, script kiddie, etc hitting this service while scanning, but it seems really odd to me that 1.1.1.1 would do this.
Here’s an excerpt from /var/log/messages, for example:
Jan 3 06:58:02 vpn openvpn[2135]: 1.1.1.1:80 Re-using SSL/TLS context
Jan 3 06:58:02 vpn openvpn[2135]: 1.1.1.1:80 LZO compression initializing
Jan 3 06:58:02 vpn openvpn[2135]: 1.1.1.1:80 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Jan 3 06:58:02 vpn openvpn[2135]: 1.1.1.1:80 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Jan 3 06:58:02 vpn openvpn[2135]: 1.1.1.1:80 Local Options String (VER=V4): ‘V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server’
Jan 3 06:58:02 vpn openvpn[2135]: 1.1.1.1:80 Expected Remote Options String (VER=V4): ‘V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client’
Jan 3 06:58:02 vpn openvpn[2135]: 1.1.1.1:80 TLS: Initial packet from [AF_INET]1.1.1.1:80, sid=6a22eb44 5adb63fe
Jan 3 06:59:02 vpn openvpn[2135]: 1.1.1.1:80 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jan 3 06:59:02 vpn openvpn[2135]: 1.1.1.1:80 TLS Error: TLS handshake failed
Jan 3 06:59:02 vpn openvpn[2135]: 1.1.1.1:80 SIGUSR1[soft,tls-error] received, client-instance restarting