Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 2760 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Site to site SSL ERR_MGMT & RECONNECT

garnser
Hi,

We've taken the decision to migrate from IPsec to SSL but we're experiencing some issues getting the tunnels connected.

We've followed https://support.astaro.com/support/index.php/Site_to_Site_SSL_VPN_Setup guide but we're currently stuck at
Server-side: WAIT_CONNECT
Client-side: ERR_MGMT (UDP)/RECONNECT (TCP)

Please see logs below:

P: 1194/UDP

Client:
2010:07:31-11:28:33 gbg-fw1 openvpn[29503]: OpenVPN 2.1_rc13 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Mar 28 2010
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: LZO compression initialized
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: Local Options hash (VER=V4): '22188c5b'
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: Expected Remote Options hash (VER=V4): 'a8f55717'
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: UDPv4 link local: [undef]
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: UDPv4 link remote: ***.***.***.***:1194
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: VERIFY OK: depth=1, /C=se/L=Kista/O=op5_AB_VPN_CA/emailAddress=hostmaster@op5.com
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: VERIFY ERROR: could not extract Common Name from X509 subject string ('/C=se/L=Kista/O=op5_AB/OU=IT/emailAddress=hostmaster@op5.com') -- note that the Common Name length is limited to 64 characters
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: TLS Error: TLS object -> incoming plaintext read error
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: TLS Error: TLS handshake failed
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: TCP/UDP: Closing socket
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: SIGHUP[soft,tls-error] received, process restarting
2010:07:31-11:28:43 gbg-fw1 openvpn[29503]: OpenVPN 2.1_rc13 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Mar 28 2010
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: LZO compression initialized
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: Local Options hash (VER=V4): '22188c5b'
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: Expected Remote Options hash (VER=V4): 'a8f55717'
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: UDPv4 link local: [undef]
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: UDPv4 link remote: ***.***.***.***:1194
2010:07:31-11:28:53 gbg-fw1 openvpn[29503]: TLS Error: Unroutable control packet received from ***.***.XX.***:1194 (via YYY.YYY.YYY.YYY) (si=3 op=P_ACK_V1)

..repeats 100 or so times...

2010:07:31-11:29:33 gbg-fw1 openvpn[29503]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2010:07:31-11:29:34 gbg-fw1 openvpn[29503]: VERIFY OK: depth=1, /C=se/L=Kista/O=op5_AB_VPN_CA/emailAddress=hostmaster@op5.com
2010:07:31-11:29:34 gbg-fw1 openvpn[29503]: VERIFY ERROR: could not extract Common Name from X509 subject string ('/C=se/L=Kista/O=op5_AB/OU=IT/emailAddress=hostmaster@op5.com') -- note that the Common Name length is limited to 64 characters
2010:07:31-11:29:34 gbg-fw1 openvpn[29503]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2010:07:31-11:29:34 gbg-fw1 openvpn[29503]: TLS Error: TLS object -> incoming plaintext read error
2010:07:31-11:29:34 gbg-fw1 openvpn[29503]: TLS Error: TLS handshake failed
2010:07:31-11:29:34 gbg-fw1 openvpn[29503]: TCP/UDP: Closing socket
2010:07:31-11:29:34 gbg-fw1 openvpn[29503]: SIGHUP[soft,tls-error] received, process restarting

Server-side:
2010:07:31-11:27:08 sth-fw1 openvpn[1795]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2010:07:31-11:27:08 sth-fw1 openvpn[1795]: TLS-Auth MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
2010:07:31-11:27:08 sth-fw1 openvpn[1795]: TUN/TAP device tun0 opened
2010:07:31-11:27:08 sth-fw1 openvpn[1795]: /bin/ip link set dev tun0 up mtu 1500
2010:07:31-11:27:08 sth-fw1 openvpn[1795]: /bin/ip addr add dev tun0 local 172.27.78.1 peer 172.27.78.2
2010:07:31-11:27:08 sth-fw1 openvpn[1795]: /usr/bin/openvpn_updown.plx up tun0 1500 1558 172.27.78.1 172.27.78.2 init
2010:07:31-11:27:11 sth-fw1 openvpn[1795]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
2010:07:31-11:27:11 sth-fw1 openvpn[1823]: UDPv4 link local (bound): [undef]:1194
2010:07:31-11:27:11 sth-fw1 openvpn[1823]: UDPv4 link remote: [undef]
2010:07:31-11:27:11 sth-fw1 openvpn[1823]: Initialization Sequence Completed

Running with TCP I get:

P: 443 / TCP

Client:
010:07:31-11:37:12 gbg-fw1 openvpn[31689]: OpenVPN 2.1_rc13 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] built on Mar 28 2010
2010:07:31-11:37:22 gbg-fw1 openvpn[31689]: WARNING: Make sure you understand the semantics of --tls-remote before using it (see the man page).
2010:07:31-11:37:22 gbg-fw1 openvpn[31689]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2010:07:31-11:37:22 gbg-fw1 openvpn[31689]: LZO compression initialized
2010:07:31-11:37:22 gbg-fw1 openvpn[31689]: Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
2010:07:31-11:37:22 gbg-fw1 openvpn[31689]: Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
2010:07:31-11:37:22 gbg-fw1 openvpn[31689]: Local Options hash (VER=V4): '958c5492'
2010:07:31-11:37:22 gbg-fw1 openvpn[31689]: Expected Remote Options hash (VER=V4): '79ef4284'
2010:07:31-11:37:22 gbg-fw1 openvpn[31689]: Attempting to establish TCP connection with ***.***.***.***:443 [nonblock]
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: TCP connection established with ***.***.***.***:443
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: TCPv4_CLIENT link local: [undef]
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: TCPv4_CLIENT link remote: ***.***.***.***:443
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: VERIFY OK: depth=1, /C=se/L=Kista/O=op5_AB_VPN_CA/emailAddress=hostmaster@op5.com
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: VERIFY ERROR: could not extract Common Name from X509 subject string ('/C=se/L=Kista/O=op5_AB/OU=IT/emailAddress=hostmaster@op5.com') -- note that the Common Name length is limited to 64 characters
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: TLS Error: TLS object -> incoming plaintext read error
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: TLS Error: TLS handshake failed
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: Fatal TLS error (check_tls_errors_co), restarting
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: TCP/UDP: Closing socket
2010:07:31-11:37:23 gbg-fw1 openvpn[31689]: SIGHUP[soft,tls-error] received, process restarting

Server:

2010:07:31-11:37:55 sth-fw1 openvpn[2483]: Re-using SSL/TLS context
2010:07:31-11:37:55 sth-fw1 openvpn[2483]: LZO compression initialized
2010:07:31-11:37:55 sth-fw1 openvpn[2483]: Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
2010:07:31-11:37:55 sth-fw1 openvpn[2483]: Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]
2010:07:31-11:37:55 sth-fw1 openvpn[2483]: Local Options hash (VER=V4): '79ef4284'
2010:07:31-11:37:55 sth-fw1 openvpn[2483]: Expected Remote Options hash (VER=V4): '958c5492'
2010:07:31-11:37:55 sth-fw1 openvpn[2483]: TCP connection established with YYY.YYY.YYY.YYY:51551
2010:07:31-11:37:55 sth-fw1 openvpn[2483]: TCPv4_SERVER link local: [undef]
2010:07:31-11:37:55 sth-fw1 openvpn[2483]: TCPv4_SERVER link remote: YYY.YYY.YYY.YYY:51551
2010:07:31-11:37:57 sth-fw1 openvpn[2483]: YYY.YYY.YYY.YYY:51551 Connection reset, restarting [0]
2010:07:31-11:37:57 sth-fw1 openvpn[2483]: TCP/UDP: Closing socket

Please advice


This thread was automatically locked due to age.
  • 0
    TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

    Are you using the same certificate that's presently in use for IPsec?

    If the IPsec connection is working, what do you expect to gain with SSL?

    Cheers - Bob
  • 0 in reply to BAlfson
    Are you using the same certificate that's presently in use for IPsec?

    If the IPsec connection is working, what do you expect to gain with SSL?

    Cheers - Bob


    No they're using different certs, should I consider using the same instead? The main reason to migrate to SSL is due to other end-point clients which is just plain Linux-servers, Free/Open/Strong-swan isn't all that great as traffic isn't treated as pure Layer 3 traffic compared to OpenVPN.
  • 0
    It appears that the cert for IPsec is correctly configured for your Astaro and that the one in use for SSL is not.  You're right to use UDP to make the SSL connection faster, and, after a discussion here earlier this year, it appears that AES encryption is faster and better than the others.
    Free/Open/Strong-swan isn't all that great as traffic isn't treated as pure Layer 3 traffic compared to OpenVPN

    What advantage does "pure Layer 3 traffic" have?

    Cheers - Bob
  • 0
    I.e. the CA needs to be re-created to contain a common-name.

    As IPsec operates somewhere between Layer 2 and 3 there's less logic compared to SSL-based VPN tunnels which allows one to use one or the other, not something that's between. IPsec simply sucks [:)]
  • 0
    I.e. the CA needs to be re-created to contain a common-name.

    I would guess that the cert used with IPsec has 'VPNId [Hostname]' with the FQDN that resolves to the IP of "External (Address)" in public DNS.  Another trick to creating a new cert that works is that all fields must have a value.

    Well, I'm willing to learn, but I don't think I've ever seen an article comparing IPsec unfavorably with SSL for site-to-site VPNs.  All of the site-to-sites we've installed over the years have been IPsec - never a problem.

    Cheers - Bob
  • 0
    I'll poke around in the certs and see if I can find a solution.

    From my experience administration has turned out easier as OpenVPN (SSL based VPN) operates more in userland making it easier for you as an administration to set general policies etc like you would to any other physical or logical interfaces. I guess it's just a matter of preference but having everything normalized regardless of being VPN or a physical connection is my preference [:)]
  • 0
    I'll poke around in the certs and see if I can find a solution.

    From my experience administration has turned out easier as OpenVPN (SSL based VPN) operates more in userland making it easier for you as an administration to set general policies etc like you would to any other physical or logical interfaces. I guess it's just a matter of preference but having everything normalized regardless of being VPN or a physical connection is my preference [:)]
  • 0
    Hm, still no love after creating a new cert with all the information =/
  • 0
    Since the one for IPsec works, try using it.  We normally use the same cert for both.

    Cheers - Bob