tls-auth for HMAC firewall not dropping unsigned connections

cobbler

I have setup OpenVPN (version 2.2.2) in server mode on my OpenWRT router. It works great and I can connect from various remote clients on the internet without any problems, using UDP protocol, and public/private keys for authentication.

I would like to also use the tls-auth directive with a pre-shared key to act as a HMAC firewall, so that "packets bearing an incorrect HMAC signature can be dropped immediately without response" (as written on OpenVPN man page).

So I have created a static key file (openvpn --genkey --secret ta.key), distributed it to each peer, and referenced it from each peer's config (tls-auth ta.key 0 on the server and tls-auth ta.key 1 on the clients). By testing connections from clients with or without a copy of the HMAC key, I can verify that clients can now only connect when using a matching tls-auth key.

However, I was expecting that after doing this, the OpenVPN service would effectively 'disappear' from port scans, being that the UDP probe of the port scan will not bear a matching HMAC signature. But a nmap scan from a remote machine still shows UDP port 1194 as open:-

$ sudo nmap -sU -p 1194 openvpn.myserver.com

Host is up (0.019s latency).
PORT     STATE         SERVICE
1194/udp open|filtered openvpn

What am I missing?

Here's my test server config:-

server 192.168.105.0 255.255.255.0

dev tun
port 1194
proto udp

verb 3

ca /etc/easy-rsa/keys/ca.crt
cert /etc/easy-rsa/keys/heracles.crt
key /etc/easy-rsa/keys/heracles.key
dh /etc/easy-rsa/keys/dh2048.pem

tls-auth /etc/easy-rsa/keys/ta.key 0

push 'route 192.168.100.0 255.255.255.0'
push 'dhcp-option DOMAIN mydomain.com'
push 'dhcp-option DNS 192.168.100.1'

Server logs suggest TLS static key is read ok at startup:-

May  7 09:51:20 OpenWrt daemon.notice openvpn(home)[23369]: Control Channel Authentication: using '/etc/easy-rsa/keys/ta.key' as a OpenVPN static key file
May  7 09:51:20 OpenWrt daemon.notice openvpn(home)[23369]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
May  7 09:51:20 OpenWrt daemon.notice openvpn(home)[23369]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication

And a sample of the OpenVPN log that shows (I think) the HMAC key being checked during a client connect:

May  7 09:52:04 OpenWrt daemon.notice openvpn(home)[23369]: 1.2.3.4:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
May  7 09:52:04 OpenWrt daemon.notice openvpn(home)[23369]: 1.2.3.4:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
May  7 09:52:04 OpenWrt daemon.notice openvpn(home)[23369]: 1.2.3.4:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
May  7 09:52:04 OpenWrt daemon.notice openvpn(home)[23369]: 1.2.3.4:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

cobbler

debbie10t wrotenmap is probably deciding that the port is open as it does not receive any ICMP traffic to the contrary when doing the probe.

Thanks, debbie10t, that makes sense now. I guess I was being overly optimistic as to how 'invisible' the service / port could appear. 🙂

cobbler

My remote clients include mobiles and laptops that roam between all sorts of networks, so I can't really lock the firewall down to any specific source IPs unfortunately. I suppose port knocking would help but I don't really fancy going down that route.

I was wondering though, if iptables could be configured to drop / reject / accept packets based on the HMAC signature. If it could do that, I don't see why we couldn't have proper stealth then. A quick bit of googling hasn't turned up anything much yet, but I will investigate that further some time...