Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 1 subscriber
  • Views 6385 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.
  • 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.
  • 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]
  • 0
    Dear bimmerdriver,

    Maybe you don't know it, but this is a user support board - users are helping other users here. The sophos employees that are active here do that on their own and in their private time (beside the beta section ...). So you don't need to YELL for them;-) .

    Regards
    Manfred
  • 0 in reply to Hallowach2
    Dear bimmerdriver,

    Maybe you don't know it, but this is a user support board - users are helping other users here. The sophos employees that are active here do that on their own and in their private time (beside the beta section ...). So you don't need to YELL for them;-) .

    Regards
    Manfred
    Thanks for your reply. I am aware that this is a user board, but that there are also sophos employees here as well. To be honest, I don't normally yell, but I am finding the silence of sophos on this matter to be exasperating. Support for openvpn was raised as a feature in 2010 and there have been 38 comments on it, all supportive. The link I included below is from 2008. It's not like they could not have at any time over the past 5 years addressed this issue.

    I sent a pm to the product manager and received no reply. I emailed sophos support and was told that my only recourse was this board. I won't quote the email directly, but I was given a lame excuse for why sophos has not responded to what is a simple trivial request. They claim that it would increase the burden on their support organization. Frankly, that is a load of BS. In my particular case, I downloaded openvpn, installed it on my computer, copied over 4 files and clicked "connect". It took more time to find the link to download the software than it took to install and start it up for the first time. On the contrary, I've spent hours trying to decode the apc file so I can get the vpn running in utm.

    Judging from the lack of response from sophos in this topic (I have not seen a single response), it costs them nothing to support this issue. Should they decide to disclose to users the format of the apc file or provide some other work around, they can continue to do nothing. They are clearly very good at doing nothing when they chose to do nothing. There is an easy out. If users have an issue with openvpn, they can get support from https://forums.openvpn.net/, so it will continue to cost sophos nothing.

    So the big question is why are they doing nothing? There are a variety of trivial ways to allow users to get around the wall they've built around openvpn, if they chose to do something. It would be a win for users and a win for sophos. So why the lack of response?
  • 0
    I ended up using a dd-wrt router which acts like an openvpn client and has only one client, the UTM gateway which connects to it (it's in DMZ). The rest of the devices connect directly to the gateway. Really annoying issue, but this could be a workaround if you have a spare dd-wrt compatible router...

    EDIT: you can also disable the wireless radio on the router if you want to be sure no external clients connect to it and skip the gateway...
  • 0 in reply to PeterPH
    I took another look at this and made some progress. I was able to hack a .apc file and insert my ca, cert and key, as well as the set the applicable config parameters. The vpn still would not start, due to the server not using tls-remote. The only way around this was to edit /var/chroot-openvpn/etc/openvpn/client/config-default. The actual config file is created on the fly in a dynamically created directory, so there is no way to simply edit the config settings directly. [:@] It's an ugly hack, but by making this change, I was able to get the vpn to at least start, but the next problem was when the server pushed the route down to the client.

    Here is the log:

    2013:03:27-18:49:40 utm9 openvpn[32023]: OpenVPN 2.1.1 i686-suse-linux [SSL] [LZO2] [EPOLL] built on Jul 9 2012
    2013:03:27-18:49:40 utm9 openvpn[32023]: MANAGEMENT: client_uid=0
    2013:03:27-18:49:40 utm9 openvpn[32023]: MANAGEMENT: client_gid=0
    2013:03:27-18:49:40 utm9 openvpn[32023]: MANAGEMENT: unix domain socket listening on /var/run/openvpn_mgmt_REF_SslCliMullvad
    2013:03:27-18:49:40 utm9 openvpn[32023]: NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables
    2013:03:27-18:49:40 utm9 openvpn[32023]: PLUGIN_INIT: POST /usr/lib/openvpn-utm.so '[/usr/lib/openvpn-utm.so] [REF_SslCliMullvad]' intercepted=PLUGIN_UP|PLUGIN_DOWN
    2013:03:27-18:49:40 utm9 openvpn[32023]: LZO compression initialized
    2013:03:27-18:49:40 utm9 openvpn[32023]: Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
    2013:03:27-18:49:40 utm9 openvpn[32023]: Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
    2013:03:27-18:49:40 utm9 openvpn[32023]: Local Options hash (VER=V4): '41690919'
    2013:03:27-18:49:40 utm9 openvpn[32023]: Expected Remote Options hash (VER=V4): '530fdded'
    2013:03:27-18:49:40 utm9 openvpn[32025]: Socket Buffers: R=[212992->131072] S=[212992->131072]
    2013:03:27-18:49:40 utm9 openvpn[32025]: UDPv4 link local: [undef]
    2013:03:27-18:49:40 utm9 openvpn[32025]: UDPv4 link remote: **.21.99.21:1194
    2013:03:27-18:49:40 utm9 openvpn[32025]: TLS: Initial packet from **.21.99.21:1194 (via ***.20.116.5), sid=bd5c4ac2 0358a570
    2013:03:27-18:49:42 utm9 openvpn[32025]: VERIFY OK: depth=2, C=NA, ST=None, L=None, O=Mullvad, CN=Mullvad CA, emailAddress=info@mullvad.net
    2013:03:27-18:49:42 utm9 openvpn[32025]: VERIFY OK: depth=1, C=NA, ST=None, L=None, O=Mullvad, CN=master.mullvad.net, emailAddress=info@mullvad.net
    2013:03:27-18:49:42 utm9 openvpn[32025]: Validating certificate key usage
    2013:03:27-18:49:42 utm9 openvpn[32025]: ++ Certificate has key usage 00a0, expects 00a0
    2013:03:27-18:49:42 utm9 openvpn[32025]: VERIFY KU OK
    2013:03:27-18:49:42 utm9 openvpn[32025]: Validating certificate extended key usage
    2013:03:27-18:49:42 utm9 openvpn[32025]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
    2013:03:27-18:49:42 utm9 openvpn[32025]: VERIFY EKU OK
    2013:03:27-18:49:42 utm9 openvpn[32025]: VERIFY OK: depth=0, C=NA, ST=None, L=None, O=Mullvad, CN=se2.mullvad.net, emailAddress=info@mullvad.net
    2013:03:27-18:49:46 utm9 openvpn[32025]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    2013:03:27-18:49:46 utm9 openvpn[32025]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    2013:03:27-18:49:46 utm9 openvpn[32025]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
    2013:03:27-18:49:46 utm9 openvpn[32025]: [se2.mullvad.net] Peer Connection Initiated with **.21.99.21:1194 (via ***.20.116.5)
    2013:03:27-18:49:48 utm9 openvpn[32025]: SENT CONTROL [se2.mullvad.net]: 'PUSH_REQUEST' (status=1)
    2013:03:27-18:49:49 utm9 openvpn[32025]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 10.8.0.1,route 10.8.0.1,topology net30,ifconfig 10.8.0.82 10.8.0.81'
    2013:03:27-18:49:49 utm9 openvpn[32025]: OPTIONS IMPORT: --ifconfig/up options modified
    2013:03:27-18:49:49 utm9 openvpn[32025]: OPTIONS IMPORT: route options modified
    2013:03:27-18:49:49 utm9 openvpn[32025]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
    2013:03:27-18:49:49 utm9 openvpn[32025]: ROUTE default_gateway=***.20.116.1
    2013:03:27-18:49:49 utm9 openvpn[32025]: TUN/TAP device tun0 opened
    2013:03:27-18:49:49 utm9 openvpn[32025]: TUN/TAP TX queue length set to 100
    2013:03:27-18:49:49 utm9 openvpn[32025]: /bin/ip link set dev tun0 up mtu 1500
    2013:03:27-18:49:49 utm9 openvpn[32025]: /bin/ip addr add dev tun0 local 10.8.0.82 peer 10.8.0.81
    2013:03:27-18:49:49 utm9 openvpn[32025]: PLUGIN_CALL: POST /usr/lib/openvpn-utm.so/PLUGIN_UP status=0
    2013:03:27-18:49:49 utm9 openvpn[32025]: /bin/ip route add **.21.99.21/32 via ***.20.116.1 dev tun0
    2013:03:27-18:49:49 utm9 openvpn[32025]: ERROR: Linux route add command failed: external program exited with error status: 2
    2013:03:27-18:49:49 utm9 openvpn[32025]: /bin/ip route add 0.0.0.0/1 via 10.8.0.81 dev tun0
    2013:03:27-18:49:49 utm9 openvpn[32025]: /bin/ip route add 128.0.0.0/1 via 10.8.0.81 dev tun0
    2013:03:27-18:49:49 utm9 openvpn[32025]: /bin/ip route add 10.8.0.1/32 via 10.8.0.81 dev tun0
    2013:03:27-18:49:49 utm9 openvpn[32025]: Initialization Sequence Completed


    If you have figured out how to work around this, please let me know.

    I'm very close to giving up on utm and setting up a pfsense router, which supports openvpn.
  • 0
    Hi, 

    1. could you ping each end after connecting?

    If so, you might be able to set the routes on the client manually.

    2. this is the firewall log, right? What does the client log show?

    3. did you check to see if any routes got set on the client?

    Barry
  • 0 in reply to BarryG
    Hi, 

    1. could you ping each end after connecting?

    If so, you might be able to set the routes on the client manually.

    2. this is the firewall log, right? What does the client log show?

    3. did you check to see if any routes got set on the client?

    Barry
    Thanks for your reply. I will explain the configuration. utm is my home router. It has an external "dhcp" interface to my isp (through which I'm also running a 6in4 tunnel with an ipv6 address in the usa) and an internal interface to which my home network is connected. I'm trying to connect utm as a client to an external openvpn server with an ip address in Europe. I'm not trying to use the vpn for all traffic (although getting that working would be a step in the right direction), but rather only selectively for some of my traffic (http and udp). As anyone who has tried to do this knows, utm not only does not support this, it makes it very difficult to do so. I was finally able to get utm to connect as a client, but only barely. The log file attached above is from the SSL VPN live log, the vpn does not start cleanly. When I connect my PC directly to the VPN, the openvpn server pushes an ip address, gateway address and dns server address, as well as a route, and it works perfectly. You an see from the above log that the server is trying to do the same thing when utm connects as a client, but it's not successful. (I have no way to get the log from the server. It's overseas hosted by a service provider.) When I enable the vpn, the lan works, but the external interface doesn't work. I can't ping anything outside the network or browse to any websites. Supposedly some people have been able to get this working, but I have no idea how they overcame the problems. They seem to be no longer posting on this forum.
  • 0
    OK.

    Maybe you can add those routes manually as Static Routes in WebAdmin?

    Barry
  • 0 in reply to BarryG
    OK.

    Maybe you can add those routes manually as Static Routes in WebAdmin?

    Barry
    Barry, thanks for the reply. I don't think this will work, because I don't know the address beforehand. The server pushes the routes, because the address is set by the server. It's trying to create a route to my external ipv4 address, which is also a problem. The log I attached is from a pc running windows 7. I may try connecting from a pc running Ubuntu to see what the log looks like for a successful connection. It may give me a better idea where the process is failing when utm connects to the server. I'm becoming increasingly skeptical that anyone has been able to get this working based on utm 9. From what I gather, there have been changes in the code so what may have been possible before may not be possible any more. I may just try to create vpn gateway using pfsense and quit banging my head against the wall trying to do it with utm.
Share Feedback
×

Submitted a Tech Support Case lately from the Support Portal?

Unfiltered HTML