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
I can pretty definitively say it’s not a local device configured with 1.1.1.1: after adding 1.1.1.1 to the firewall the dropped packets get logged and they are coming in on the internet interface, not the internal LAN interface.
The host is also acting as a firewall/router between the internet and the internal LAN and the the only other device on the internet interface is the fiber modem . . .
This is UDP. Anybody can generate an initial packet with 1.1.1.1 as the source address to try and attack you, which will cause an OpenVPN log message that looks like yours[ * ] and Internet routers will happily forward it to your public IP if they don’t have source filtering to only accept the expected IP ranges from their other interfaces.
Ideally, if you want to avoid that (and any other connection which you do not approve, regardless of its’ source IP) - and it’s feasible to you - OpenVPN has an awesome feature of using a static pre-shared key (shared between the server and all the authorized clients) - to digitally HMAC sign all the packets sent to the server, including the first one. If the received packet does not validate, it is just dropped. If you want to use this functionality, you need to first create a key:
openvpn --genkey --secret ta.key
and then, on openvpn.conf, you use the tls-auth directive, that way:
On the client’s openvpn.conf, you add:
tls-auth ta.key 1
While on the server’s openvpn.conf, you add:
tls-auth ta.key 0
Hope this helps.
P.S. As a bonus, if OpenVPN is the only server listening on your public facing interface, and all other traffic is dropped by your firewall, the host becomes… invisible… to any scanner from the outside, because no scanning packets are ever answered… which I think is a Good Thing ™.
[ * ] eventually no TLS key negotiation takes place, probably because your return packets do not go back to the attacker
Ah. I think that must be what is happening. From a traceroute, it looks like at least att.net and ntt.net would need to check that their configs will correctly drop 1.1.1.1 traffic from inappropriate interfaces…I don’t see that happening if I just call them up…
Also, 1.1.1.1 is not the only source…I’m getting this from many dozens of hosts…I’m now wondering if those are all spoofed addresses, too. And what would be the point if these hosts are never going to get a response? Just DOS?
I haven’t had a chance yet, but will definitely check out the HMAC signing.
Three “quick” questions about the HMAC signing:
Does the ta.key just go into /etc/openvpn (the same directory where the server config files are? I don’t see any mention in the documentation of where the key needs to reside. It also does not indicate whether this could be an absolute path, for example, like “tls-auth /etc/openvpn/ta.key 0” in the config files? And for perms, just the same as the other files in /etc/openvpn which are currently 600, owned by root.root, at least on my server?
Second, some of my servers are remote and the documentation mentions “no support for rollover”. If I copy the key to one remote client and change both the client and server configs, to try it out, but then change the server config back to having it commented out so I can work on other clients, will the client that has it enabled in its config be unable to connect? (I.e. client uses signing but server does not).
And lastly, I assume this is supported for linux and Windows clients…do you know offhand if it’s supported for Android clients? I haven’t researched this yet so if you don’t happen to know, no worries.
It is similar to all other files you’re referencing in your config file, like ca.crt, server.crt, etc. If they all work without explicit path, so should this. Explicit/relative paths works for sure, but not always relevant for clients who use unfortunate platforms such as Microsoft Windows and many times dump their config at some random place (I always instructed my MS users to just “run openvpn config from this directory” and provided them with a zip file with everything inside…). As for permissions… as long as the server can read it, do whatever you want.
When you enable this on the server, no client can connect unless it has this also set. I am not sure what rollover means (maybe rotating keys and having the old one still work for some time? but that is also true for changing your ca.crt… it won’t work). If you enable and everybody gets disconnected, then from the client POV the server is just offline (remember - it doesn’t answer any packet…), and if they are configured to always retry, once you remove the setting, they should be able to go back… but I can’t sign off this. I used tls-auth since my first OpenVPN server back in 2005
As for Android, it worked for me. I use “OpenVPN for Android” app by Arne Schwabe.
