[Openvpn-users] TLS Handshake not happening

Discussion:

Jean-Pierre Schwickerath

2005-02-17 21:24:19 UTC

Hello everyone,

I just hit a problem tonight with a Windows XP SP2 box that I need to
connect to a well working OpenVPN installation on a GNU/Linux Debian
Testing box. Server and Client are running 2.0-rc14.

There have been similar problems posted on the list recently. All had to
do with messages like "Waiting for TUN/TAP interface to come up"... The
solution was most of the time something with the DHCP-Client that was
not working or a firewall active on the box. None of this applies to
me.port 5000 proto udp
dev tap1

ca ca.crt
cert server.crt
key server.key # This file is secret
crl-verify revoked_certs.crl

dh dh1024.pem

server-bridge 192.168.100.230 255.255.255.0 192.168.100.129
192.168.100.144

push "dhcp-option DNS 192.168.100.250"
push "dhcp-option WINS 192.168.100.251"

client-to-client
keepalive 15 60
ping-timer-rem

comp-lzo

user nobody
group nogroup
persist-key
persist-tun

status openvpn-status.log

verb 6

client

dev tap
dev-node VPN-UNIMEDES
proto udp

# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote vpn.unimedes.com 5000

# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite

# Most clients don't need to bind to
# a specific local port number.
nobind

# SSL/TLS parms.
# See the server config file for more
# description.
ca unimedes-ca.crt
cert unimedes-user.crt
key unimedes-user.key

# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo

# Set log file verbosity.
verb 3

I also get this message, but only when the connection is actually
successful. The given message is repeated 2-3 times and then, the IP is
assigned and everything works well.
But, if I then happen to push F1 to send a SIGUSR1, OpenVPN releases the
Network interface (you see Windows showing a toolbox with "Network cable
has been disconnected"), waits 2 seconds and then tries to establish a
new connection. But it fails. The same problem also happens, if I close
a successful tunnel by pressing F4 and the try to reconnect right
afterwards.

There is no way to establish the connection again, except to close
openvpn and wait a few minutes. Manually disabling the TAP interface and
reactivating it does not change anything.

On the client, I see the following:

UDPv4 link remote: YYY.YYY.YYY.YYY:5000
UDPv4 WRITE [14] to YYY.YYY.YYY.YYY:5000: P_CONTROL_HARD_RESET_CLIENT_V2
kid=0 [ ] pid=0 DATA len=0
UDPv4 READ [-1] from [undef]: DATA UNDEF len=-1
UDPv4 WRITE [14] to YYY.YYY.YYY.YYY:5000: P_CONTROL_HARD_RESET_CLIENT_V2
kid=0 [ ] pid=0 DATA len=0
UDPv4 WRITE [14] to YYY.YYY.YYY.YYY:5000: P_CONTROL_HARD_RESET_CLIENT_V2
kid=0 [ ] pid=0 DATA len=0
UDPv4 WRITE [14] to YYY.YYY.YYY.YYY:5000: P_CONTROL_HARD_RESET_CLIENT_V2
kid=0 [ ] pid=0 DATA len=0

and so on....
On the Server side:

MULTI: multi_create_instance called
XXX.XXX.XXX.XXX:29214 Re-using SSL/TLS context
XXX.XXX.XXX.XXX:29214 LZO compression initialized
XXX.XXX.XXX.XXX:29214 Control Channel MTU parms [ L:1574 D:138 EF:38
EB:0 ET:0 EL:0 ]
XXX.XXX.XXX.XXX:29214 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:23
ET:32 EL:0 AF:3/1 ]
XXX.XXX.XXX.XXX:29214 Local Options String: 'V4,dev-type tap,link-mtu
1574,tun-mtu 1532,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize
128,key-method 2,tls-server'
XXX.XXX.XXX.XXX:29214 Expected Remote Options String: 'V4,dev-type
tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,comp-lzo,cipher BF-CBC,auth
SHA1,keysize 128,key-method 2,tls-client'
XXX.XXX.XXX.XXX:29214 Local Options hash (VER=V4): 'f7df56b8'
XXX.XXX.XXX.XXX:29214 Expected Remote Options hash (VER=V4): 'd79ca330'
XXX.XXX.XXX.XXX:29214 UDPv4 READ [14] from XXX.XXX.XXX.XXX:29214:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
XXX.XXX.XXX.XXX:29214 TLS: Initial packet from XXX.XXX.XXX.XXX:29214,
sid=90f51ef3 0188edfa XXX.XXX.XXX.XXX:29214 UDPv4 WRITE [26] to
XXX.XXX.XXX.XXX:29214: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0
DATA len=0
XXX.XXX.XXX.XXX:29214 UDPv4 READ [14] from XXX.XXX.XXX.XXX:29214:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
XXX.XXX.XXX.XXX:29214 UDPv4 WRITE [26] to XXX.XXX.XXX.XXX:29214:
P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
XXX.XXX.XXX.XXX:29214 UDPv4 READ [14] from XXX.XXX.XXX.XXX:29214:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
XXX.XXX.XXX.XXX:29214 UDPv4 WRITE [26] to XXX.XXX.XXX.XXX:29214:
P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
XXX.XXX.XXX.XXX:29214 UDPv4 WRITE [14] to XXX.XXX.XXX.XXX:29214:
P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
XXX.XXX.XXX.XXX:29214 UDPv4 READ [14] from XXX.XXX.XXX.XXX:29214:
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
XXX.XXX.XXX.XXX:29214 UDPv4 WRITE [22] to XXX.XXX.XXX.XXX:29214:
P_ACK_V1 kid=0 [ 0 ] XXX.XXX.XXX.XXX:29214 UDPv4 READ [14] from
XXX.XXX.XXX.XXX:29214: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0
DATA len=0 XXX.XXX.XXX.XXX:29214 UDPv4 WRITE [22] to
XXX.XXX.XXX.XXX:29214: P_ACK_V1 kid=0 [ 0 ] XXX.XXX.XXX.XXX:29214 UDPv4
WRITE [14] to XXX.XXX.XXX.XXX:29214: P_CONTROL_HARD_RESET_SERVER_V2
kid=0 [ ] pid=0 DATA len=0

While this box has the problem, I have no trouble to connect to the
server from another linux client at the same time. Unfortunately I
currently have no other windows box on which I could test it...

Something I noticed is that when the Windows Box is trying to get a
connection to the server and I start a connection from a linux client
(from a different location), then I get the following message twice on
the linux box:
TLS Error: Unroutable control packet received from YYY.YYY.YYY.YYY:5000
(si=3 op=P_ACK_V1)

followed by
TLS: Initial packet from YYY.YYY.YYY.YYY:5000, sid=b433ca37 93e1d2a5

and the rest of a successful connection. And right then, the windows box
also issues a
TLS Error: Unroutable control packet received from YYY.YYY.YYY.YYY:5000
(si=3 op=P_ACK_V1)
message and succeeds in the connection.

So I'm little bit confused because there seems to be some problem on the
server (see how the connection goes on when I connect with the linux
box) but only the windows XP client seems to be complaining by not
establishing a connection.

The client and server config files are attached.

Does someone have a clue?

Jean-Pierre

--

Stephen Carville

2005-02-17 21:41:19 UTC

Permalink

On Thursday 17 February 2005 3:23 pm, Jean-Pierre Schwickerath wrote:

Few things:

In the client config you have:

remote YYY.YYY.YYY.YYY 5000

I've never used bridging so maybe it is different but I think you need an
actual address here.

I've seen the "Unroutable control packet" error message when the keys at one
end did not have a good signature and when the clocks between the boxes were
too far out of sync.

Post by Jean-Pierre Schwickerath
Hello everyone,
I just hit a problem tonight with a Windows XP SP2 box that I need to
connect to a well working OpenVPN installation on a GNU/Linux Debian
Testing box. Server and Client are running 2.0-rc14.
There have been similar problems posted on the list recently. All had to
do with messages like "Waiting for TUN/TAP interface to come up"... The
solution was most of the time something with the DHCP-Client that was
not working or a firewall active on the box. None of this applies to
me.port 5000 proto udp
dev tap1
ca ca.crt
cert server.crt
key server.key # This file is secret
crl-verify revoked_certs.crl
dh dh1024.pem
server-bridge 192.168.100.230 255.255.255.0 192.168.100.129
192.168.100.144
push "dhcp-option DNS 192.168.100.250"
push "dhcp-option WINS 192.168.100.251"
client-to-client
keepalive 15 60
ping-timer-rem
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 6
client
dev tap
dev-node VPN-UNIMEDES
proto udp
# The hostname/IP and port of the server.
# You can have multiple remote entries
# to load balance between the servers.
remote vpn.unimedes.com 5000
# Keep trying indefinitely to resolve the
# host name of the OpenVPN server. Very useful
# on machines which are not permanently connected
# to the internet such as laptops.
resolv-retry infinite
# Most clients don't need to bind to
# a specific local port number.
nobind
# SSL/TLS parms.
# See the server config file for more
# description.
ca unimedes-ca.crt
cert unimedes-user.crt
key unimedes-user.key
# Enable compression on the VPN link.
# Don't enable this unless it is also
# enabled in the server config file.
comp-lzo
# Set log file verbosity.
verb 3
I also get this message, but only when the connection is actually
successful. The given message is repeated 2-3 times and then, the IP is
assigned and everything works well.
But, if I then happen to push F1 to send a SIGUSR1, OpenVPN releases the
Network interface (you see Windows showing a toolbox with "Network cable
has been disconnected"), waits 2 seconds and then tries to establish a
new connection. But it fails. The same problem also happens, if I close
a successful tunnel by pressing F4 and the try to reconnect right
afterwards.
There is no way to establish the connection again, except to close
openvpn and wait a few minutes. Manually disabling the TAP interface and
reactivating it does not change anything.
UDPv4 link remote: YYY.YYY.YYY.YYY:5000
UDPv4 WRITE [14] to YYY.YYY.YYY.YYY:5000: P_CONTROL_HARD_RESET_CLIENT_V2
kid=0 [ ] pid=0 DATA len=0
UDPv4 READ [-1] from [undef]: DATA UNDEF len=-1
UDPv4 WRITE [14] to YYY.YYY.YYY.YYY:5000: P_CONTROL_HARD_RESET_CLIENT_V2
kid=0 [ ] pid=0 DATA len=0
UDPv4 WRITE [14] to YYY.YYY.YYY.YYY:5000: P_CONTROL_HARD_RESET_CLIENT_V2
kid=0 [ ] pid=0 DATA len=0
UDPv4 WRITE [14] to YYY.YYY.YYY.YYY:5000: P_CONTROL_HARD_RESET_CLIENT_V2
kid=0 [ ] pid=0 DATA len=0
and so on....
MULTI: multi_create_instance called
XXX.XXX.XXX.XXX:29214 Re-using SSL/TLS context
XXX.XXX.XXX.XXX:29214 LZO compression initialized
XXX.XXX.XXX.XXX:29214 Control Channel MTU parms [ L:1574 D:138 EF:38
EB:0 ET:0 EL:0 ]
XXX.XXX.XXX.XXX:29214 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:23
ET:32 EL:0 AF:3/1 ]
XXX.XXX.XXX.XXX:29214 Local Options String: 'V4,dev-type tap,link-mtu
1574,tun-mtu 1532,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize
128,key-method 2,tls-server'
XXX.XXX.XXX.XXX:29214 Expected Remote Options String: 'V4,dev-type
tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,comp-lzo,cipher BF-CBC,auth
SHA1,keysize 128,key-method 2,tls-client'
XXX.XXX.XXX.XXX:29214 Local Options hash (VER=V4): 'f7df56b8'
XXX.XXX.XXX.XXX:29214 Expected Remote Options hash (VER=V4): 'd79ca330'
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
XXX.XXX.XXX.XXX:29214 TLS: Initial packet from XXX.XXX.XXX.XXX:29214,
sid=90f51ef3 0188edfa XXX.XXX.XXX.XXX:29214 UDPv4 WRITE [26] to
XXX.XXX.XXX.XXX:29214: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0
DATA len=0
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ ] pid=0 DATA len=0
P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
P_ACK_V1 kid=0 [ 0 ] XXX.XXX.XXX.XXX:29214 UDPv4 READ [14] from
XXX.XXX.XXX.XXX:29214: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0
DATA len=0 XXX.XXX.XXX.XXX:29214 UDPv4 WRITE [22] to
XXX.XXX.XXX.XXX:29214: P_ACK_V1 kid=0 [ 0 ] XXX.XXX.XXX.XXX:29214 UDPv4
WRITE [14] to XXX.XXX.XXX.XXX:29214: P_CONTROL_HARD_RESET_SERVER_V2
kid=0 [ ] pid=0 DATA len=0
While this box has the problem, I have no trouble to connect to the
server from another linux client at the same time. Unfortunately I
currently have no other windows box on which I could test it...
Something I noticed is that when the Windows Box is trying to get a
connection to the server and I start a connection from a linux client
(from a different location), then I get the following message twice on
TLS Error: Unroutable control packet received from YYY.YYY.YYY.YYY:5000
(si=3 op=P_ACK_V1)
followed by
TLS: Initial packet from YYY.YYY.YYY.YYY:5000, sid=b433ca37 93e1d2a5
and the rest of a successful connection. And right then, the windows box
also issues a
TLS Error: Unroutable control packet received from YYY.YYY.YYY.YYY:5000
(si=3 op=P_ACK_V1)
message and succeeds in the connection.
So I'm little bit confused because there seems to be some problem on the
server (see how the connection goes on when I connect with the linux
box) but only the windows XP client seems to be complaining by not
establishing a connection.
The client and server config files are attached.
Does someone have a clue?
Jean-Pierre

--
Stephen Carville
Systems and Network Administrator
310-342-3602
***@totalflood.com

James Yonan

2005-02-17 21:42:10 UTC

Permalink

The client is sending a P_CONTROL_HARD_RESET_CLIENT_V2 message to the
server. The server then replies with a P_CONTROL_HARD_RESET_SERVER_V2
message. But the client doesn't receive this message.

It looks like you have a one-way link. The client can talk to the server
but the server can't talk with the client. So there's some kind of
blockage or misdirection happening in the server -> client direction.
Client firewall maybe?

James

Jean-Pierre Schwickerath

2005-02-18 08:18:22 UTC

Permalink

Hello James,

Post by James Yonan
The client is sending a P_CONTROL_HARD_RESET_CLIENT_V2 message to the
server. The server then replies with a P_CONTROL_HARD_RESET_SERVER_V2
message. But the client doesn't receive this message.
It looks like you have a one-way link. The client can talk to the
server but the server can't talk with the client. So there's some
kind of blockage or misdirection happening in the server -> client
direction. Client firewall maybe?

Thanks a thousand times for this advice... It was not a client firewall
but a "firewall" on the NAT-Router which registered the incoming packets
from the server as attack. Sometimes firewalls do treat UDP in a really
strange way.

Jean-Pierre