search

RustyDust / ovpn-to-apc

Convert OpenVPN profiles to an APC file that can be imported into a Sophos/Astaro UTM
14 stars 6 forks source link

"VERIFY X509NAME ERROR" on my UTM #2

Open sturze opened 8 years ago

sturze commented 8 years ago

i have a working configuration (tried with Tunnelblick-client) inclusive all certificates and keys. now i tried to convert my ovpn config to apc to establish a connection with my utm and now getting this issue...

can anyone tell me whats wrong, or why it is not working?

2016:01:19-22:26:58 UTM openvpn[2222]: TLS: Initial packet from [AF_INET]x.x.x.x:1194 (via [AF_INET]x.x.x.x%eth1), sid=d865c36c 98e7b4b3
2016:01:19-22:26:58 UTM openvpn[2222]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2016:01:19-22:26:58 UTM openvpn[2222]: VERIFY OK: depth=1, C=DE, ST=BY, L=Muenchen, O=LCServer, OU=changeme, CN=changeme, name=changeme, emailAddress=mail@host.domain
2016:01:19-22:26:58 UTM openvpn[2222]: VERIFY X509NAME ERROR: C=DE, ST=BY, L=Muenchen, O=LCServer, OU=changeme, CN=server, name=changeme, emailAddress=mail@host.domain, must be changeme
2016:01:19-22:26:58 UTM openvpn[2222]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2016:01:19-22:26:58 UTM openvpn[2222]: TLS Error: TLS object -> incoming plaintext read error
2016:01:19-22:26:58 UTM openvpn[2222]: TLS Error: TLS handshake failed

on the commandline its seems to be valid

openssl verify -CAfile ca.crt client.crt 
client.crt: OK
RustyDust commented 8 years ago

Shooting from the hip I'd say that SSLv3 is disabled on one side of the connection. See also https://lists.ubuntu.com/archives/foundations-bugs/2013-July/155861.html

Not knowing whether the SSLv3 was specified in the config somewhere it's hard to guess where the problem really is. But I'll have a look when I'm in Munich tomorrow and see what my UTM tells me ;)

RustyDust commented 8 years ago

I just checked: None of my UTMs support SSLv3 anymore. So switching to TLS should solve your problem. You can verify this for example by running

nmap --script +ssl-enum-ciphers ip.of.utm

and against your OVPN box. I guess the OVPN box still supports SSLv3 whereas the UTM doesn't.

sturze commented 8 years ago

seems not so :disappointed: against the OVPN box it sais TLS1 against the UTM (inside, LAN ip) it is not working?! or did you meen to the WAN-Address?

maybe i'm doing something wrong on the UTM...? just in case, thats what i allready did: i converted the OVPN-config file to apc --> imported into the UTM (site-to-site VPN, ssl, new ssl conn. , select client in dropdown, upload apc file) and then done? or do i need to import certificates? i did not, because it seems like they are integrated into the apc file already, or am i wrong?

sorry, for these dumb questions, but this is my first try with UTM.

RustyDust commented 8 years ago

The procedure is correct and so are your assumptions about the certificates. What I wanted to say is that OpenVPN stopped supporting SSLv3 with version 2.0.11. I don't know what version is running on your UTM but on my UTMs the version of OpenVPN are newer than 2.0.11 and thus don#t support SSLv3 at all. Since you didn't post any output from the check commands or the relevant portions of the OVPN config file I have no idea how I could help you any further than re-stating that using SSLv3 isn't supported on the UTM anymore.

sturze commented 8 years ago

the result of the check against the openvpn server 

Not shown: 973 filtered ports
PORT      STATE  SERVICE
22/tcp    closed ssh
23/tcp    closed telnet
25/tcp    closed smtp
53/tcp    closed domain
80/tcp    open   http
110/tcp   open   pop3
143/tcp   closed imap
443/tcp   open   https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors: 
|       NULL
|     cipher preference: server
|     warnings: 
|       Key exchange parameters of lower strength than certificate key
|       Weak certificate signature: SHA1
|_  least strength: A
465/tcp   closed smtps
587/tcp   closed submission
873/tcp   closed rsync
993/tcp   closed imaps
995/tcp   closed pop3s
1494/tcp  closed citrix-ica
2170/tcp  closed eyetv
3000/tcp  closed ppp
3128/tcp  closed squid-http
3283/tcp  closed netassistant
3389/tcp  closed ms-wbt-server
4443/tcp  closed pharos
5900/tcp  closed vnc
7000/tcp  closed afs3-fileserver
7004/tcp  closed afs3-kaserver
8000/tcp  closed http-alt
8008/tcp  closed http
8080/tcp  closed http-proxy
14000/tcp closed scotty-ft

and against my UTM on the WAN-IP (should connect as client) is that correct?

PORT      STATE  SERVICE
21/tcp    closed ftp
22/tcp    closed ssh
23/tcp    closed telnet
25/tcp    open   smtp
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|     compressors: 
|       DEFLATE
|       NULL
|     cipher preference: client
|   TLSv1.1: 
|     ciphers: 
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 2048) - A
|     compressors: 
|       DEFLATE
|       NULL
|     cipher preference: client
|_  least strength: C
53/tcp    closed domain
80/tcp    closed http
110/tcp   open   pop3
143/tcp   closed imap
443/tcp   open   https
| ssl-enum-ciphers: 
|   TLSv1.0: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.1: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 2048) - C
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors: 
|       NULL
|     cipher preference: server
|_  least strength: C
465/tcp   closed smtps
587/tcp   closed submission
873/tcp   closed rsync
993/tcp   closed imaps
995/tcp   closed pop3s
1494/tcp  closed citrix-ica
2170/tcp  open   eyetv
3000/tcp  closed ppp
3128/tcp  closed squid-http
3283/tcp  closed netassistant
3389/tcp  closed ms-wbt-server
5900/tcp  closed vnc
7000/tcp  closed afs3-fileserver
7004/tcp  closed afs3-kaserver
8000/tcp  closed http-alt
8008/tcp  closed http
8080/tcp  closed http-proxy
14000/tcp closed scotty-ft

cant see any SSL 3 there?! whats the issue?!

sturze commented 8 years ago

nobody?

snorre-k commented 8 years ago

Hi,

this error results from an openvpn option used in UTM9. The option tls-remote "%SERVER_DN%" should not be used. To unset this option open the file /var/sec/chroot-openvpn/etc/openvpn/client/config-default and put a semicolon befor tls-remote:

/var/sec/chroot-openvpn/etc/openvpn/client/config-default: ;tls-remote "[<SERVER_DN>]"

Hope this helps in your case. I also hope (not tested) that this setting is permanent.

CU

sturze commented 8 years ago

Cool thing! Thank you Snorre-k!

seems to do the trick.

but i ran into another... can you give me a hint whats wrong? seems to be connected but cannot ping through the tunnel on any time... also tries to reconnect due inactivity timeout?! is it on the server-side? had client-to side for now, maybe thats a thing to know too...

2016:04:01-12:38:27 UTMWall openvpn[21623]: [server] Inactivity timeout (--ping-restart), restarting
2016:04:01-12:38:27 UTMWall openvpn[21623]: id="2204" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN down" variant="ssl" connection="REF_SslCliOpenvpn" address="192.168.1.253"
2016:04:01-12:38:27 UTMWall openvpn[21623]: PLUGIN_CALL: POST /usr/lib/openvpn/plugins/openvpn-plugin-utm.so/PLUGIN_ROUTE_PREDOWN status=0
2016:04:01-12:38:27 UTMWall openvpn[21623]: /bin/ip route del 10.8.0.1/32 proto 41
2016:04:01-12:38:27 UTMWall openvpn[21623]: PLUGIN_CALL: POST /usr/lib/openvpn/plugins/openvpn-plugin-utm.so/PLUGIN_DOWN status=0
2016:04:01-12:38:27 UTMWall openvpn[21623]: Closing TUN/TAP interface
2016:04:01-12:38:27 UTMWall openvpn[21623]: /bin/ip addr del dev tun0 local 10.8.0.82 peer 10.8.0.81
2016:04:01-12:38:27 UTMWall openvpn[21623]: PLUGIN_CLOSE: /usr/lib/openvpn/plugins/openvpn-plugin-utm.so
2016:04:01-12:38:27 UTMWall openvpn[21623]: SIGHUP[soft,ping-restart] received, process restarting
2016:04:01-12:38:27 UTMWall openvpn[21623]: OpenVPN 2.3.0 i686-suse-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH] [IPv6] built on Jul 8 2015
2016:04:01-12:38:27 UTMWall openvpn[21623]: Restart pause, 10 second(s)
2016:04:01-12:38:28 UTMWall openvpn[21623]: MANAGEMENT: Client connected from /var/run/openvpn_mgmt_REF_SslCliOpenvpn
2016:04:01-12:38:28 UTMWall openvpn[21623]: MANAGEMENT: CMD 'state'
2016:04:01-12:38:37 UTMWall openvpn[21623]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.
2016:04:01-12:38:37 UTMWall openvpn[21623]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
2016:04:01-12:38:37 UTMWall openvpn[21623]: PLUGIN_INIT: POST /usr/lib/openvpn/plugins/openvpn-plugin-utm.so '[/usr/lib/openvpn/plugins/openvpn-plugin-utm.so] [REF_SslCliOpenvpn]' intercepted=PLUGIN_UP|PLUGIN_DOWN|PLUGIN_ROUTE_UP|PLUGIN_ROUTE_PREDOWN
2016:04:01-12:38:37 UTMWall openvpn[21623]: Socket Buffers: R=[212992->131072] S=[212992->131072]
2016:04:01-12:38:37 UTMWall openvpn[21623]: UDPv4 link local: [undef]
2016:04:01-12:38:37 UTMWall openvpn[21623]: UDPv4 link remote: [AF_INET]267.94.123.135:1194
2016:04:01-12:38:37 UTMWall openvpn[21623]: TLS: Initial packet from [AF_INET]267.94.123.135:1194 (via [AF_INET]192.168.1.253%eth1), sid=c07454a1 9bdbb2a8
2016:04:01-12:38:38 UTMWall openvpn[21623]: VERIFY OK: depth=1, C=DE, ST=BY, L=Muenchen, O=LCServer, OU=changeme, CN=changeme, name=changeme, emailAddress=mail@host.domain
2016:04:01-12:38:38 UTMWall openvpn[21623]: VERIFY OK: depth=0, C=DE, ST=BY, L=Muenchen, O=LCServer, OU=changeme, CN=server, name=changeme, emailAddress=mail@host.domain
2016:04:01-12:38:38 UTMWall openvpn[21623]: MANAGEMENT: Client disconnected
2016:04:01-12:38:38 UTMWall openvpn[21623]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
2016:04:01-12:38:38 UTMWall openvpn[21623]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2016:04:01-12:38:38 UTMWall openvpn[21623]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
2016:04:01-12:38:38 UTMWall openvpn[21623]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
2016:04:01-12:38:38 UTMWall openvpn[21623]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
2016:04:01-12:38:38 UTMWall openvpn[21623]: [server] Peer Connection Initiated with [AF_INET]267.94.123.135:1194 (via [AF_INET]192.168.1.253%eth1)
2016:04:01-12:38:41 UTMWall openvpn[21623]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2016:04:01-12:38:41 UTMWall openvpn[21623]: PUSH: Received control message: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.82 10.8.0.81'
2016:04:01-12:38:41 UTMWall openvpn[21623]: OPTIONS IMPORT: timers and/or timeouts modified
2016:04:01-12:38:41 UTMWall openvpn[21623]: OPTIONS IMPORT: --ifconfig/up options modified
2016:04:01-12:38:41 UTMWall openvpn[21623]: OPTIONS IMPORT: route options modified
2016:04:01-12:38:41 UTMWall openvpn[21623]: ROUTE_GATEWAY 192.168.1.254/255.255.255.0 IFACE=eth1 HWADDR=00:0c:29:0d:6a:f0
2016:04:01-12:38:41 UTMWall openvpn[21623]: TUN/TAP device tun0 opened
2016:04:01-12:38:41 UTMWall openvpn[21623]: TUN/TAP TX queue length set to 100
2016:04:01-12:38:41 UTMWall openvpn[21623]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
2016:04:01-12:38:41 UTMWall openvpn[21623]: /bin/ip link set dev tun0 up mtu 1500
2016:04:01-12:38:41 UTMWall openvpn[21623]: /bin/ip addr add dev tun0 local 10.8.0.82 peer 10.8.0.81
2016:04:01-12:38:41 UTMWall openvpn[21623]: PLUGIN_CALL: POST /usr/lib/openvpn/plugins/openvpn-plugin-utm.so/PLUGIN_UP status=0
2016:04:01-12:38:41 UTMWall openvpn[21623]: /bin/ip route add 10.8.0.1/32 via 10.8.0.81 proto 41 dev tun0
2016:04:01-12:38:41 UTMWall openvpn[21623]: id="2203" severity="info" sys="SecureNet" sub="vpn" event="Site-to-site VPN up" variant="ssl" connection="REF_SslCliOpenvpn" address="192.168.1.253"
2016:04:01-12:38:41 UTMWall openvpn[21623]: PLUGIN_CALL: POST /usr/lib/openvpn/plugins/openvpn-plugin-utm.so/PLUGIN_ROUTE_UP status=0
2016:04:01-12:38:41 UTMWall openvpn[21623]: Initialization Sequence Completed
2016:04:01-12:38:42 UTMWall openvpn[21623]: MANAGEMENT: Client connected from /var/run/openvpn_mgmt_REF_SslCliOpenvpn
2016:04:01-12:38:42 UTMWall openvpn[21623]: MANAGEMENT: CMD 'state'
2016:04:01-12:38:52 UTMWall openvpn[21623]: MANAGEMENT: Client disconnected
snorre-k commented 8 years ago

Issue could be triggered by the reverse routing (routing back to the ping sending IP). If no route back to your network is set at the VPN server, packets cannot be sent back to you. To verify this, try to ping from the UTM9. If this works, you have to setup a SNAT or Masquerading on UTM9. Unfortunately this is not easy because the UTM9 Web interface does not list the tunneling interfaces (tun). To understand the problem have a look at: https://community.sophos.com/products/unified-threat-management/f/51/t/22844

All these procedures are error-prone as long as Sophos will not integrate "real" OpenVPN as a client into their product.

zyv commented 7 years ago

Instead of hacking your UTM, adjust your OpenVPN config by including the CN of the server certificate:

tls-remote "/CN=certificate-server"

Works for me.