Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 6393 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

Update on connecting to OpenVPN Server

bimmerdriver
I made some progress manually converting an ovpn file into an apc file. I have been able to get utm to accept the file. However, utm will not connect to the server.

Here is what appears to be the problem from the log:

2013:03:03-15:51:20 utm9 openvpn[20476]: VERIFY OK: depth=2, C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA, emailAddress=info@mullvad.net
2013:03:03-15:51:20 utm9 openvpn[20476]: VERIFY OK: depth=1, C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net, emailAddress=info@mullvad.net
2013:03:03-15:51:20 utm9 openvpn[20476]: VERIFY X509NAME ERROR: C=NA, ST=None, L=None, O=Mullvad, CN=se2.mullvad.net, emailAddress=info@mullvad.net, must be C=NA, L=None, O=Mullvad, CN=se2.mullvad.net, emailAddress=info@mullvad.net
2013:03:03-15:51:20 utm9 openvpn[20476]: TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2013:03:03-15:51:20 utm9 openvpn[20476]: TLS Error: TLS object -> incoming plaintext read error

It seems to be complaining about the ST field in the server DN.

Here is a link to a screen capture of the apc file that was loaded into utm and resulted in the log file above, opened in notepad++:


You can see that there is no ST field in the server DN. (In case you're wondering, the vpn server does not rely upon authentication. It simply uses the key. The username and password fields are placeholders.)

Since I have nothing else to try, if I assume the problem is that utm is unhappy with the format of the server DN due to the missing ST field, and correct it to what utm seems to be asking for, it rejects the apc file when I try to load it, saying the config is corrupt. I'm quite sure the file is formatted correctly (the character preceding the server DN is the length in hex), but it obviously utm is not happy with it.

Here is a link to apc file that seems like it should be correct, but is rejected:


I was able to partially decode the apc file from this snip out of here.

0x04 0x06 0x04 1234 0x04 0x04 0x04 0x08 0x03 0x0C 0x00 0x00 0x00 0x0d 0x0a
0x03 tcp 0x08 0x00 0x00 0x00 protocol 0x0d 0x0a
0x03 MD5 0x18 0x00 0x00 0x00 authentication_algorithm 0x01 0x49 0x0e 0x00 0x00  0x0a 
0x0b 0x00 0x00 0x00 certificate 0x01 0x77 0x0c 0x00 0x00  0x0a
0x07 0x00 0x00 0x00 ca_cert 0x01 0x77 0x03 0x00 0x00  0x0a
0x03 0x00 0x00 0x00 key 0x0a
0x0e REF_1234567890 0x08 0x00 0x00 0x00 username 0x08 0x81 0x0b 0x00 0x00 compression 0x0a 
0x0b AES-128-CBC 0x14 0x00 0x00 0x00 encryption_algorithm 0x0a
0x20 1234567890123456789012 0x08 0x00 0x00 0x00 password 0x0a
0x61 /C=country/L=Town/O=Organization/CN=hostname/emailAddress=me@my.org 0x09 0x00 0x00 0x00 server_dn 0x0a
0x03 443 0x0b 0x00 0x00 0x00 server_port 0x0a
0x08 astaro01 0x0e 0x00 0x00 0x00 server_address 0x00

ASIDE: My editorial comment on the apc file format, as an engineer, is that it's one the most bizarre formats I've ever seen. Whoever thought it was a good idea to intermix ascii and hex in one file really deserves to be locked up in stocks and have peasants throw rotten eggs and tomatoes at him. The file is very difficult to decode and also very difficult to edit. It would be impossible without notepad++ or another hex editor. Ever heard of XML?



I have found a number of changes in the apc file format since Patrick Schneider was looking at it, including the header and the field for compression, which I was able to figure out, but I have no idea what the "engine" field in the third last line of the apc file is, nor do I know why utm is not happy with the modified file that it's rejecting.

If someone else who's trying to get this working wants to collaborate, let me know. I'd be happy to share my work.

However, I've said this before and I'll say it again. Sophos could make this matter a lot simpler if someone would disclose the format of the apc file. Why the silence? What do you have to hide? Surely you don't think anyone will copy the apc file format do you?

PS. If the tone of my post gives you the impression that I'm not very happy with sophos, it's because I'm not very happy with sophos.


This thread was automatically locked due to age.
Parents
  • 0
    I contacted sophos support about this issue. They claim to not have any documentation on the format of the apc file. They also claim to not be "locking down" openvpn. Hmm... They said the only place I can expect any support on this issue is this bulletin board, unless I take out a support contract.

    I'll try a bit more, but barring a breakthrough, unless someone else has been able to decode the apc file or unless someone from sophos will disclose the format of the apc file, utm interoperating with an openvpn server is dead in the water.
Reply
  • 0
    I contacted sophos support about this issue. They claim to not have any documentation on the format of the apc file. They also claim to not be "locking down" openvpn. Hmm... They said the only place I can expect any support on this issue is this bulletin board, unless I take out a support contract.

    I'll try a bit more, but barring a breakthrough, unless someone else has been able to decode the apc file or unless someone from sophos will disclose the format of the apc file, utm interoperating with an openvpn server is dead in the water.
Children
  • 0 in reply to bimmerdriver
    I installed openvpn on one of my pcs to verify that the config files I have are okay. They are. Here is the log from the connection:

    Mon Mar 04 21:59:09 2013 VERIFY OK: depth=2, C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA, emailAddress=info@mullvad.net
    Mon Mar 04 21:59:09 2013 VERIFY OK: depth=1, C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net, emailAddress=info@mullvad.net
    Mon Mar 04 21:59:09 2013 Validating certificate key usage
    Mon Mar 04 21:59:09 2013 ++ Certificate has key usage  00a0, expects 00a0
    Mon Mar 04 21:59:09 2013 VERIFY KU OK
    Mon Mar 04 21:59:09 2013 Validating certificate extended key usage
    Mon Mar 04 21:59:09 2013 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
    Mon Mar 04 21:59:09 2013 VERIFY EKU OK
    Mon Mar 04 21:59:09 2013 VERIFY OK: depth=0, C=NA, ST=None, L=None, O=Mullvad, CN=se2.mullvad.net, emailAddress=info@mullvad.net
    Mon Mar 04 21:59:13 2013 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Mon Mar 04 21:59:13 2013 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Mar 04 21:59:13 2013 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Mon Mar 04 21:59:13 2013 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Mon Mar 04 21:59:13 2013 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA

    You can see that it verified with this: C=NA, ST=None, L=None, O=Mullvad, CN=se2.mullvad.net, emailAddress=info@mullvad.net

    I have tried putting this text into the apc file, with the correct length and the resulting apc file is rejected by utm. I have no idea why it's not accepted, because the only error is "config package is corrupt".

    [SIZE="5"]WOULD SOMEONE FROM SOPHOS PLEASE COMMENT ON THIS?[/SIZE]
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML