[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Problem switchign from shared secret to TLS


  • Subject: Re: [Openvpn-users] Problem switchign from shared secret to TLS
  • From: Stephen Carville <stephen@xxxxxxxxxxxxxx>
  • Date: Thu, 16 Dec 2004 09:53:55 -0800 (PST)

On Thu, 16 Dec 2004, James Yonan wrote:

- On Thu, 16 Dec 2004, Stephen Carville wrote:
- 
- > I have been testing OpenVPN for about three weeks now using a shared 
- > key.  It has proven to be very robust and performs as well as or 
- > better than the IPSEC tunnels I use now.
- > 
- > In the interest of periodic rekeying, I tried switching to TLS
- > authentication.
- > 
- > Now the connection will not come up and which ever side is designaed 
- > as the client (tls-client) gets a bunch of the following messages in 
- > the log
- > 
- > TLS Error: Unroutable control packet received from 
- > 209.189.103.196:5000 (si=3 op=P_CONTROL_V1)
- > TLS Error: Unroutable control packet received from 
- > 209.189.103.196:5000 (si=3 op=P_CONTROL_V1)
- > 
- > I am using OpenVPN version 2.0_beta15
- 
- That error occurs when an openvpn daemon gets packets from another daemon 
- which claim to represent a previously negotiated TLS session, except the 
- daemon has no memory of ever establishing such an association.
- 
- I tested your configuration locally using 2.0_beta15 and it works fine.  
- The error you cited above could occur due to a routing or firewall
- misconfiguration or even due to a network outage.  In the case of a
- network outage, after the net comes back up, the ping-restart should have
- kicked in and restarted things.
- 
- Make sure you don't have a one-way situation where UDP packets can only 
- travel in one direction.
- 
- Also make sure you don't have a crosstalk situation where more than one 
- daemon tries to simultaneously talk to a another daemon which is not 
- running in server mode.
- 
- Finally, you could try to get it running in TCP mode first (--proto 
- tcp-client and --proto tcp-server) then switch back to UDP when everything 
- is debugged.  Running in TCP mode would probably help expose the reason 
- behind the unroutable control packets, since the connection-oriented 
- semantics of TCP mode will prevent the kind of one-way connections and 
- crosstalk which can occur with UDP when there are firewall, router, or 
- openvpn daemon misconfigurations.

FWIW I looked deeper into the logs and found:

Dec 16 07:18:49 warlock openvpn[8777]: VERIFY ERROR: depth=0,
error=unable to get local issuer certificate:  
/C=US/ST=California/O=Nationwide.Totalflood/OU=Wizards.of.Century.Blvd/CN=shannon/emailAddress=domainadmin@xxxxxxxxxxxxxx

Dec 16 07:18:49 warlock openvpn[8777]: TLS_ERROR: BIO read 
tls_read_plaintext error: error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Dec 16 07:18:49 warlock openvpn[8777]: TLS Error: TLS object -> 
incoming plaintext read error

Dec 16 07:18:49 warlock openvpn[8777]: TLS Error: TLS handshake failed

Dec 16 07:18:49 warlock openvpn[8777]: Fatal decryption error 
(check_tls_errors_dowork), restarting

Dec 16 07:18:49 warlock openvpn[8777]: TCP/UDP: Closing socket

If I swapped tls-server <=> tls-client the error alway occuered none 
the client side. 

For some reason the certificate exchange was failing.  I couldn't find
any specific reason why so I just created new keys for each machine 
and resigned them with the "corporate" CA. All is fine now.
 
- James
- 
- > Configurations:
- > 
- > 'Client' side
- > #tls-server
- > tls-client
- > dh ssl.key/dh1024.key
- > ca ssl.crt/vpn-ca.crt
- > cert ssl.crt/shannon.crt
- > key ssl.key/shannon.key
- > # secret ssl.key/warlock-shannon.key
- > 
- > comp-lzo
- > dev tun0
- > 
- > local 209.189.103.196
- > remote 216.117.196.95
- > ifconfig 192.168.254.1 192.168.254.2
- > port 5000
- > proto udp
- > 
- > up up/warlock-shannon.up
- > 
- > user nobody
- > group nobody
- > 
- > ping 15
- > ping-restart 45
- > ping-timer-rem
- > persist-tun
- > persist-key
- > 
- > verb 3
- > 
- > 'Server' side
- > 
- > tls-server
- > #tls-client
- > dh ssl.key/dh1024.key
- > ca ssl.crt/vpn-ca.crt
- > cert ssl.crt/warlock.crt
- > key ssl.key/warlock.key
- > #secret ssl.key/warlock-shannon.key
- > 
- > dev tun0
- > comp-lzo
- > 
- > local 216.117.196.95
- > remote 209.189.103.196
- > ifconfig 192.168.254.2 192.168.254.1
- > port 5000
- > proto udp
- > 
- > up up/warlock-shannon.up
- > 
- > user nobody
- > group nobody
- > 
- > ping 15
- > ping-restart 45
- > ping-timer-rem
- > persist-tun
- > persist-key
- > 
- > verb 3
-