Real-world example of OpenVPN port getting probed, Was: [Openvpn-users] OpenVPN stopped working

[James Y. <ji...@yo...>]

Mr E_T <tr...@ar...> said:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sun, 13 Jun 2004 02:35 pm, dav...@th... wrote:
> > dav...@th... wrote:
> > 
> > > dav...@th... wrote:
> > >
> > >> Hello.. I don't know quite when it happened but sometime in the last 
> > >> few weeks my vpn stopped working.  I can't seem to figure out why it 
> > >> stopped working.  I had upgrade to the 2.6 kernel, and shorewall 2.0 
> > >> but i had it working for at least a week after i did that.. then it 
> > >> just stopped working at some point.  Now, when i try to do "openvpn 
> > >> --config configfile" it just sits there spitting out rrrrr and wwwww 
> > >> for each host.  The only error i'm getting is this:
> > >>
> > >> TLS Error: TLS handshake failed
> > >> TLS Error: TLS key negotiation failed to occur within 60 seconds
> > >>
> > >> ideas?
> > >
> > >
> > It was an error with shorewall.  I had "openvpn:5000 ..." in the tunnels 
> > file evidently this is not a good thing.
> > 
> I had the same problem - using a non standard port
> It turned out to be an unauthorised ip trying to connect - it locked all
clients out with the above errors.
> The server also showed the same errors.

If you are running a point-to-point tunnel, you can use --tls-auth to filter
out unauthorized traffic.  Static-key-based OpenVPN tunnels also have
--tls-auth protection "built-in". 

The --mode server mode doesn't support --tls-auth yet, only vanilla SSL/TLS,
which means that while unauthorized traffic is still always blocked from
getting past the VPN into the internal network, such traffic may have a larger
DoS effect such as interfering with SSL/TLS negotiations. (Note that adding
--mode server --tls-auth support is on the to-do list for 2.0).

Think of --tls-auth as like a cryptographic firewall.  The packet is
identified as unauthorized immediately upon reception and is dropped in the
same way that a firewall would drop a packet without responding to it.

In SSL/TLS mode without --tls-auth, there is a back-and-forth
challenge/response protocol occurring which eventually leads to cryptographic
authentication.  The problem is that an attacker (or just a machine somewhere
on the net spewing forth garbage packets to your IP/port) can still grab the
server's attention and force it to play along in the initial
challenge-response sequence.  Eventually the server will figure out that the
handshake isn't really going anywhere and that the client doesn't have a valid
cert/key, but that might not happen until several packets have been exchanged
in both directions, causing interference to legitimate clients trying to
connect at the same time.

As an example, here is a real-world case from my syslog (that's happening as I
type) where one of my tunnels is getting probed by an unauthorized machine:

Jun 13 10:06:17 [anya] TLS Error: unknown opcode received from
209.86.112.102:10007 op=13
Jun 13 10:06:32 [anya] TLS Error: unknown opcode received from
209.86.112.102:10007 op=29
Jun 13 10:06:47 [anya] TLS Error: unknown opcode received from
209.86.112.102:10007 op=18
Jun 13 10:07:03 [anya] TLS Error: unknown opcode received from
209.86.112.102:10007 op=27
Jun 13 10:07:17 [anya] TLS: Initial packet from 209.86.112.102:10007,
sid=6307b625 b06f2431
Jun 13 10:07:17 [anya] Authenticate/Decrypt packet error: packet HMAC
authentication failed
Jun 13 10:07:17 [anya] TLS Error: incoming packet authentication failed from
209.86.112.102:10007

Now the "unknown opcode" lines represent packets which obviously don't belong
to OpenVPN and can therefore be discarded.  But the line that says "TLS:
Initial packet" shows that the attacking machine actually crafted a packet
that looks like the initial packet of a TLS authentication sequence.  But
immediately, OpenVPN applies the --tls-auth HMAC (digital signature) test to
the packet and discards it without sending any response to
UDP:209.86.112.102:10007 which is the (possibly forged) source address of the
probe.

While this is all happening, a legitimate connection occurs on the tunnel from
111.222.333.444 (IP addr edited from the original):

Jun 13 10:34:49 [anya] TLS: Initial packet from 111.222.333.444:10007,
sid=136317ad 832e27fb
Jun 13 10:34:53 [anya] TLS Error: unknown opcode received from
209.86.112.102:10007 op=26
Jun 13 10:35:01 [anya] VERIFY OK: depth=1, [cert info]
Jun 13 10:35:01 [anya] VERIFY OK: depth=0, [cert info]
Jun 13 10:35:03 [anya] Data Channel Encrypt: Cipher 'BF-CBC' initialized with
128 bit key
Jun 13 10:35:03 [anya] Data Channel Encrypt: Using 160 bit message hash 'SHA1'
for HMAC authentication
Jun 13 10:35:03 [anya] Data Channel Decrypt: Cipher 'BF-CBC' initialized with
128 bit key
Jun 13 10:35:03 [anya] Data Channel Decrypt: Using 160 bit message hash 'SHA1'
for HMAC authentication
Jun 13 10:35:04 [anya] Control Channel: TLSv1, cipher TLSv1/SSLv3
EDH-RSA-DES-CBC3-SHA, 2048 bit RSA
Jun 13 10:35:04 [anya] [anya] Peer Connection Initiated with 111.222.333.444:10007
Jun 13 10:35:08 [anya] TLS Error: Unknown data channel key ID or IP address
received from 209.86.112.102:10007: 5 (see FAQ for more info on this error)
Jun 13 10:35:22 [anya] TLS Error: unknown opcode received from
209.86.112.102:10007 op=21
Jun 13 10:35:40 [anya] TLS Error: unknown opcode received from
209.86.112.102:10007 op=17

Line 1 shows OpenVPN seeing the first packet come from the legitimate machine
111.222.333.444.  Note how the attacker's probe packet (line 2) comes right
inside of the legitimate authentication sequence, yet doesn't affect the
successful completion of the handshake.

James