[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: James Yonan <jim@xxxxxxxxx>
  • Date: Thu, 16 Dec 2004 02:50:18 -0700 (MST)

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.

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

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users