Windows installer with updated pkcs11-helper (1.22) available for testing

Hi all,

Those of you who use pkcs11 on Windows: could you please test this new Windows installer:

<http://build.openvpn.net/downloads/releases/openvpn-install-2.4.3-I602.exe>

The previous installer(s) had pkcs11-helper 1.11. This one has 1.22, so some regression testing would be good to have.

I'd like to push the updated installer out early next week, preferably on Monday.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

Hi Samuli,

nice to see that pkcs11 support is still included in the Windows version; I can test the installer on monday morning(no Windows laptop in my house ;)) I will let you know my findings.

cheers,

JJK

Hi JJK,

Excellent, thanks! I will push out the new installer if everything looks good at your end.

Samuli

Hi all,

good news and bad news:

+ the pkcs11 stuff works as expected, no problems there
- with openvpn 2.4.3 my existing setup using "redirect-gateway def1" stopped working!

I'll downgrade OpenVPN to see if this problem was already there in 2.3.XX ; what happens is this:
- openvpn wants to add a direct route to the VPN server
- there happen to be TWO gateways to that server with the SAME IP address, one via wired ethernet, one via wireless
- openvpn gets confused and says "route gateway is ambiguous" and refuses to add it
- after that, all traffic is jammed, as there is no direct route to the VPN server itself, and thus all encrypted traffic is fed back into the tunnel, where it is encrypted again, etc etc ("biting your own tail").

Disconnecting either wired or wireless solves the issue AFTER restarting OpenVPN. Annoying. It looks like a (minor) patch is needed to deal with this special case

cheers,

JJK

Hi,

Thanks for testing! I will push out the new installer tomorrow, hopefully in the morning (EEST).

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

2017-07-17 17:01 GMT+05:00 Jan Just Keijser <[email protected]...>:

@mattock , can we have community meeting, please ?

there were a discussion (regarding changes in openvpn-gui <--> openvpn-core interoperation) on how to serve routing issues.

there were two suggestions, either make route errors fatal or translate them to openvpn-gui level.

currently, it is no good

(yes, current error would not have been resolved by those changes, but error indication would be more clear)

Follow-up:

this problem is NOT present in OpenVPN 2.3.17; the same warning appears (route gateway is ambiguous) but the route is added anyway. This seems to be a regression in 2.4.

JJK

Hi,

Can we have a log, please?

gert

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

attached: config and log (with hostnames anonymized)

JJK

Mon Jul 17 14:18:33 2017 us=360410 Current Parameter Settings:

Mon Jul 17 14:18:33 2017 us=360410   config = 'nikhef-udp-pkcs11.ovpn'
Mon Jul 17 14:18:33 2017 us=360410   mode = 0
Mon Jul 17 14:18:33 2017 us=360410   show_ciphers = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   show_digests = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   show_engines = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   genkey = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   key_pass_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   show_tls_ciphers = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   connect_retry_max = 0
Mon Jul 17 14:18:33 2017 us=360410 Connection profiles [0]:
Mon Jul 17 14:18:33 2017 us=360410   proto = udp
Mon Jul 17 14:18:33 2017 us=360410   local = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   local_port = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   remote = 'vpnserver'
Mon Jul 17 14:18:33 2017 us=360410   remote_port = '1194'
Mon Jul 17 14:18:33 2017 us=360410   remote_float = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   bind_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   bind_local = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   bind_ipv6_only = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   connect_retry_seconds = 5
Mon Jul 17 14:18:33 2017 us=360410   connect_timeout = 120
Mon Jul 17 14:18:33 2017 us=360410   socks_proxy_server = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   socks_proxy_port = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   tun_mtu = 1500
Mon Jul 17 14:18:33 2017 us=360410   tun_mtu_defined = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   link_mtu = 1500
Mon Jul 17 14:18:33 2017 us=360410   link_mtu_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   tun_mtu_extra = 0
Mon Jul 17 14:18:33 2017 us=360410   tun_mtu_extra_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   mtu_discover_type = -1
Mon Jul 17 14:18:33 2017 us=360410   fragment = 0
Mon Jul 17 14:18:33 2017 us=360410   mssfix = 1450
Mon Jul 17 14:18:33 2017 us=360410   explicit_exit_notification = 0
Mon Jul 17 14:18:33 2017 us=360410 Connection profiles END
Mon Jul 17 14:18:33 2017 us=360410   remote_random = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ipchange = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   dev = 'tun'
Mon Jul 17 14:18:33 2017 us=360410   dev_type = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   dev_node = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   lladdr = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   topology = 1
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_local = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_remote_netmask = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_noexec = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_nowarn = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_local = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_netbits = 0
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_remote = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   shaper = 0
Mon Jul 17 14:18:33 2017 us=360410   mtu_test = 0
Mon Jul 17 14:18:33 2017 us=360410   mlock = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   keepalive_ping = 0
Mon Jul 17 14:18:33 2017 us=360410   keepalive_timeout = 0
Mon Jul 17 14:18:33 2017 us=360410   inactivity_timeout = 0
Mon Jul 17 14:18:33 2017 us=360410   ping_send_timeout = 0
Mon Jul 17 14:18:33 2017 us=360410   ping_rec_timeout = 0
Mon Jul 17 14:18:33 2017 us=360410   ping_rec_timeout_action = 0
Mon Jul 17 14:18:33 2017 us=360410   ping_timer_remote = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   remap_sigusr1 = 0
Mon Jul 17 14:18:33 2017 us=360410   persist_tun = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   persist_local_ip = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   persist_remote_ip = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   persist_key = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   passtos = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   resolve_retry_seconds = 1000000000
Mon Jul 17 14:18:33 2017 us=360410   resolve_in_advance = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   username = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   groupname = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   chroot_dir = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   cd_dir = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   writepid = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   up_script = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   down_script = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   down_pre = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   up_restart = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   up_delay = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   daemon = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   inetd = 0
Mon Jul 17 14:18:33 2017 us=360410   log = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   suppress_timestamps = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   machine_readable_output = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   nice = 0
Mon Jul 17 14:18:33 2017 us=360410   verbosity = 5
Mon Jul 17 14:18:33 2017 us=360410   mute = 0
Mon Jul 17 14:18:33 2017 us=360410   gremlin = 0
Mon Jul 17 14:18:33 2017 us=360410   status_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   status_file_version = 1
Mon Jul 17 14:18:33 2017 us=360410   status_file_update_freq = 60
Mon Jul 17 14:18:33 2017 us=360410   occ = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   rcvbuf = 0
Mon Jul 17 14:18:33 2017 us=360410   sndbuf = 0
Mon Jul 17 14:18:33 2017 us=360410   sockflags = 0
Mon Jul 17 14:18:33 2017 us=360410   fast_io = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   comp.alg = 2
Mon Jul 17 14:18:33 2017 us=360410   comp.flags = 1
Mon Jul 17 14:18:33 2017 us=360410   route_script = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   route_default_gateway = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   route_default_metric = 0
Mon Jul 17 14:18:33 2017 us=360410   route_noexec = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   route_delay = 5
Mon Jul 17 14:18:33 2017 us=360410   route_delay_window = 30
Mon Jul 17 14:18:33 2017 us=360410   route_delay_defined = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   route_nopull = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   route_gateway_via_dhcp = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   allow_pull_fqdn = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   [redirect_default_gateway local=0]
Mon Jul 17 14:18:33 2017 us=360410   management_addr = '127.0.0.1'
Mon Jul 17 14:18:33 2017 us=360410   management_port = '25340'
Mon Jul 17 14:18:33 2017 us=360410   management_user_pass = 'stdin'
Mon Jul 17 14:18:33 2017 us=360410   management_log_history_cache = 250
Mon Jul 17 14:18:33 2017 us=360410   management_echo_buffer_size = 100
Mon Jul 17 14:18:33 2017 us=360410   management_write_peer_info_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   management_client_user = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   management_client_group = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   management_flags = 6
Mon Jul 17 14:18:33 2017 us=360410   shared_secret_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   key_direction = 0
Mon Jul 17 14:18:33 2017 us=360410   ciphername = 'BF-CBC'
Mon Jul 17 14:18:33 2017 us=360410   ncp_enabled = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   ncp_ciphers = 'AES-256-GCM:AES-128-GCM'
Mon Jul 17 14:18:33 2017 us=360410   authname = 'SHA1'
Mon Jul 17 14:18:33 2017 us=360410   prng_hash = 'SHA1'
Mon Jul 17 14:18:33 2017 us=360410   prng_nonce_secret_len = 16
Mon Jul 17 14:18:33 2017 us=360410   keysize = 0
Mon Jul 17 14:18:33 2017 us=360410   engine = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   replay = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   mute_replay_warnings = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   replay_window = 64
Mon Jul 17 14:18:33 2017 us=360410   replay_time = 15
Mon Jul 17 14:18:33 2017 us=360410   packet_id_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   use_iv = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   test_crypto = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   tls_server = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   tls_client = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   key_method = 2
Mon Jul 17 14:18:33 2017 us=360410   ca_file = 'digicert.pem'
Mon Jul 17 14:18:33 2017 us=360410   ca_path = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   dh_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   cert_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   extra_certs_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   priv_key_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   pkcs12_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   cryptoapi_cert = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   cipher_list = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   tls_verify = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   tls_export_cert = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   verify_x509_type = 0
Mon Jul 17 14:18:33 2017 us=360410   verify_x509_name = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   crl_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ns_cert_type = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 65535
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_ku[i] = 0
Mon Jul 17 14:18:33 2017 us=360410   remote_cert_eku = 'TLS Web Server Authentication'
Mon Jul 17 14:18:33 2017 us=360410   ssl_flags = 0
Mon Jul 17 14:18:33 2017 us=360410   tls_timeout = 2
Mon Jul 17 14:18:33 2017 us=360410   renegotiate_bytes = -1
Mon Jul 17 14:18:33 2017 us=360410   renegotiate_packets = 0
Mon Jul 17 14:18:33 2017 us=360410   renegotiate_seconds = 3600
Mon Jul 17 14:18:33 2017 us=360410   handshake_window = 60
Mon Jul 17 14:18:33 2017 us=360410   transition_window = 3600
Mon Jul 17 14:18:33 2017 us=360410   single_session = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   push_peer_info = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   tls_exit = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   tls_auth_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   tls_crypt_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_providers = eTPkcs11.dll
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_protected_authentication = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_private_mode = 00000000
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_cert_private = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_pin_cache_period = -1
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_id = 'SafeNet\x2C\x20Inc\x2E/eToken/00a3659c/Jan\x20Just/36343132443132424330433945434336'
Mon Jul 17 14:18:33 2017 us=360410   pkcs11_id_management = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   server_network = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   server_netmask = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   server_network_ipv6 = ::
Mon Jul 17 14:18:33 2017 us=360410   server_netbits_ipv6 = 0
Mon Jul 17 14:18:33 2017 us=360410   server_bridge_ip = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   server_bridge_netmask = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   server_bridge_pool_start = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   server_bridge_pool_end = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_pool_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_pool_start = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_pool_end = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_pool_netmask = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_pool_persist_filename = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_pool_persist_refresh_freq = 600
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_pool_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_pool_base = ::
Mon Jul 17 14:18:33 2017 us=360410   ifconfig_ipv6_pool_netbits = 0
Mon Jul 17 14:18:33 2017 us=360410   n_bcast_buf = 256
Mon Jul 17 14:18:33 2017 us=360410   tcp_queue_limit = 64
Mon Jul 17 14:18:33 2017 us=360410   real_hash_size = 256
Mon Jul 17 14:18:33 2017 us=360410   virtual_hash_size = 256
Mon Jul 17 14:18:33 2017 us=360410   client_connect_script = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   learn_address_script = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   client_disconnect_script = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   client_config_dir = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   ccd_exclusive = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   tmp_dir = 'C:\TEMP\'
Mon Jul 17 14:18:33 2017 us=360410   push_ifconfig_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   push_ifconfig_local = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   push_ifconfig_remote_netmask = 0.0.0.0
Mon Jul 17 14:18:33 2017 us=360410   push_ifconfig_ipv6_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   push_ifconfig_ipv6_local = ::/0
Mon Jul 17 14:18:33 2017 us=360410   push_ifconfig_ipv6_remote = ::
Mon Jul 17 14:18:33 2017 us=360410   enable_c2c = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   duplicate_cn = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   cf_max = 0
Mon Jul 17 14:18:33 2017 us=360410   cf_per = 0
Mon Jul 17 14:18:33 2017 us=360410   max_clients = 1024
Mon Jul 17 14:18:33 2017 us=360410   max_routes_per_client = 256
Mon Jul 17 14:18:33 2017 us=360410   auth_user_pass_verify_script = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   auth_user_pass_verify_script_via_file = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   auth_token_generate = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   auth_token_lifetime = 0
Mon Jul 17 14:18:33 2017 us=360410   client = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   pull = ENABLED
Mon Jul 17 14:18:33 2017 us=360410   auth_user_pass_file = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   show_net_up = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   route_method = 3
Mon Jul 17 14:18:33 2017 us=360410   block_outside_dns = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ip_win32_defined = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   ip_win32_type = 3
Mon Jul 17 14:18:33 2017 us=360410   dhcp_masq_offset = 0
Mon Jul 17 14:18:33 2017 us=360410   dhcp_lease_time = 31536000
Mon Jul 17 14:18:33 2017 us=360410   tap_sleep = 0
Mon Jul 17 14:18:33 2017 us=360410   dhcp_options = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   dhcp_renew = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   dhcp_pre_release = DISABLED
Mon Jul 17 14:18:33 2017 us=360410   domain = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   netbios_scope = '[UNDEF]'
Mon Jul 17 14:18:33 2017 us=360410   netbios_node_type = 0
Mon Jul 17 14:18:33 2017 us=360410   disable_nbt = DISABLED

Mon Jul 17 14:18:33 2017 us=360410 OpenVPN 2.4.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Jul 14 2017
Mon Jul 17 14:18:33 2017 us=360410 Windows version 6.1 (Windows 7) 64bit
Mon Jul 17 14:18:33 2017 us=360410 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Enter Management Password:
Mon Jul 17 14:18:33 2017 us=360410 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Mon Jul 17 14:18:33 2017 us=360410 Need hold release from management interface, waiting...
Mon Jul 17 14:18:33 2017 us=875211 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
Mon Jul 17 14:18:33 2017 us=984411 MANAGEMENT: CMD 'state on'
Mon Jul 17 14:18:33 2017 us=984411 MANAGEMENT: CMD 'log all on'
Mon Jul 17 14:18:34 2017 us=78012 MANAGEMENT: CMD 'echo all on'
Mon Jul 17 14:18:34 2017 us=78012 MANAGEMENT: CMD 'hold off'
Mon Jul 17 14:18:34 2017 us=78012 MANAGEMENT: CMD 'hold release'
Mon Jul 17 14:18:34 2017 us=78012 PKCS#11: Adding PKCS#11 provider 'eTPkcs11.dll'
Mon Jul 17 14:18:36 2017 us=948417 MANAGEMENT: CMD 'password [...]'
Mon Jul 17 14:18:36 2017 us=995217 LZO compression initializing
Mon Jul 17 14:18:36 2017 us=995217 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Mon Jul 17 14:18:36 2017 us=995217 MANAGEMENT: >STATE:1500293916,RESOLVE,,,,,,
Mon Jul 17 14:18:36 2017 us=995217 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Mon Jul 17 14:18:36 2017 us=995217 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Mon Jul 17 14:18:36 2017 us=995217 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Mon Jul 17 14:18:36 2017 us=995217 TCP/UDP: Preserving recently used remote address: [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:36 2017 us=995217 Socket Buffers: R=[8192->8192] S=[8192->8192]
Mon Jul 17 14:18:36 2017 us=995217 UDP link local: (not bound)
Mon Jul 17 14:18:36 2017 us=995217 UDP link remote: [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:36 2017 us=995217 MANAGEMENT: >STATE:1500293916,WAIT,,,,,,
Mon Jul 17 14:18:37 2017 us=10817 MANAGEMENT: >STATE:1500293917,AUTH,,,,,,
Mon Jul 17 14:18:37 2017 us=10817 TLS: Initial packet from [AF_INET]222.222.97.13:1194, sid=64c40702 59cc6324
Mon Jul 17 14:18:37 2017 us=10817 VERIFY OK: depth=2, C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Assured ID Root CA
Mon Jul 17 14:18:37 2017 us=10817 VERIFY OK: depth=1, C=NL, ST=Noord-Holland, L=Amsterdam, O=TERENA, CN=TERENA SSL CA 3
Mon Jul 17 14:18:37 2017 us=10817 VERIFY KU OK
Mon Jul 17 14:18:37 2017 us=10817 Validating certificate extended key usage
Mon Jul 17 14:18:37 2017 us=10817 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mon Jul 17 14:18:37 2017 us=10817 VERIFY EKU OK
Mon Jul 17 14:18:37 2017 us=10817 VERIFY OK: depth=0, C=NL, ST=Noord-Holland, L=Amsterdam, O=Nikhef, CN=vpnserver
Mon Jul 17 14:18:37 2017 us=385217 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Mon Jul 17 14:18:37 2017 us=385217 [vpnserver] Peer Connection Initiated with [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:38 2017 us=446019 MANAGEMENT: >STATE:1500293918,GET_CONFIG,,,,,,
Mon Jul 17 14:18:38 2017 us=446019 SENT CONTROL [vpnserver]: 'PUSH_REQUEST' (status=1)
Mon Jul 17 14:18:38 2017 us=446019 PUSH: Received control message: 'PUSH_REPLY,ifconfig-ipv6 2001:610:120:e034::1002/64 2001:610:120:e034::1,route 222.222.97.13 255.255.255.255 net_gateway,dhcp-option DISABLE-NBT,dhcp-option DNS 222.222.97.228,dhcp-option DOMAIN nikhef.nl,tun-ipv6,route 10.200.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.200.0.14 10.200.0.13' Mon Jul 17 14:18:38 2017 us=446019 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore.
Mon Jul 17 14:18:38 2017 us=446019 OPTIONS IMPORT: timers and/or timeouts modified
Mon Jul 17 14:18:38 2017 us=446019 OPTIONS IMPORT: --ifconfig/up options modified
Mon Jul 17 14:18:38 2017 us=446019 OPTIONS IMPORT: route options modified
Mon Jul 17 14:18:38 2017 us=446019 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mon Jul 17 14:18:38 2017 us=446019 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:406 ET:0 EL:3 ]
Mon Jul 17 14:18:38 2017 us=446019 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jul 17 14:18:38 2017 us=446019 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mon Jul 17 14:18:38 2017 us=446019 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul 17 14:18:38 2017 us=446019 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Jul 17 14:18:38 2017 us=446019 WARNING: INSECURE cipher with block size less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate by using a --cipher with a larger block size (e.g. AES-256-CBC).
Mon Jul 17 14:18:38 2017 us=446019 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Jul 17 14:18:38 2017 us=446019 WARNING: cipher with small block size in use, reducing reneg-bytes to 64MB to mitigate SWEET32 attacks.
Mon Jul 17 14:18:38 2017 us=446019 interactive service msg_channel=404
Mon Jul 17 14:18:38 2017 us=446019 ROUTE_GATEWAY 111.111.135.254/255.255.252.0 I=23 HWADDR=80:19:34:57:3e:9c
Mon Jul 17 14:18:38 2017 us=492819 open_tun
Mon Jul 17 14:18:38 2017 us=492819 TAP-WIN32 device [vpn0] opened: \\.\Global\{0A98E2CD-E31A-4D47-B5EF-03F98D3A49FB}.tap
Mon Jul 17 14:18:38 2017 us=492819 TAP-Windows Driver Version 9.21
Mon Jul 17 14:18:38 2017 us=492819 TAP-Windows MTU=1500
Mon Jul 17 14:18:38 2017 us=492819 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.200.0.14/255.255.255.252 on interface {0A98E2CD-E31A-4D47-B5EF-03F98D3A49FB} [DHCP-serv: 10.200.0.13, lease-time: 31536000]
Mon Jul 17 14:18:38 2017 us=492819 DHCP option string: 0f096e69 6b686566 2e6e6c06 04c2ab61 e42b0601 04000000 02
Mon Jul 17 14:18:38 2017 us=492819 Successful ARP Flush on interface [17] {0A98E2CD-E31A-4D47-B5EF-03F98D3A49FB}
Mon Jul 17 14:18:38 2017 us=492819 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Mon Jul 17 14:18:38 2017 us=492819 MANAGEMENT: >STATE:1500293918,ASSIGN_IP,,10.200.0.14,,,,,2001:610:120:e034::1002
Mon Jul 17 14:18:38 2017 us=492819 add_route_ipv6(2001:610:120:e034::/64 -> 2001:610:120:e034::1002 metric 0) dev vpn0
Mon Jul 17 14:18:38 2017 us=492819 IPv6 route addition via service succeeded
Mon Jul 17 14:18:43 2017 us=1227 TEST ROUTES: 3/3 succeeded len=2 ret=1 a=1 u/d=up
Mon Jul 17 14:18:43 2017 us=1227 C:\Windows\system32\route.exe ADD 222.222.97.13 MASK 255.255.255.255 111.111.135.254
Mon Jul 17 14:18:43 2017 us=1227 Warning: route gateway is ambiguous: 111.111.135.254 (2 matches)
Mon Jul 17 14:18:43 2017 us=1227 Route addition via service failed
Mon Jul 17 14:18:43 2017 us=1227 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.200.0.13
Mon Jul 17 14:18:43 2017 us=16827 Route addition via service succeeded
Mon Jul 17 14:18:43 2017 us=16827 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.200.0.13
Mon Jul 17 14:18:43 2017 us=16827 Route addition via service succeeded
Mon Jul 17 14:18:43 2017 us=16827 MANAGEMENT: >STATE:1500293923,ADD_ROUTES,,,,,,
Mon Jul 17 14:18:43 2017 us=16827 C:\Windows\system32\route.exe ADD 222.222.97.13 MASK 255.255.255.255 111.111.135.254
Mon Jul 17 14:18:43 2017 us=16827 Warning: route gateway is ambiguous: 111.111.135.254 (2 matches)
Mon Jul 17 14:18:43 2017 us=16827 Route addition via service failed
Mon Jul 17 14:18:43 2017 us=16827 C:\Windows\system32\route.exe ADD 10.200.0.1 MASK 255.255.255.255 10.200.0.13
Mon Jul 17 14:18:43 2017 us=16827 Route addition via service succeeded
Mon Jul 17 14:18:43 2017 us=16827 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Mon Jul 17 14:18:43 2017 us=16827 Initialization Sequence Completed
Mon Jul 17 14:18:43 2017 us=16827 MANAGEMENT: >STATE:1500293923,CONNECTED,SUCCESS,10.200.0.14,222.222.97.13,1194,,,2001:610:120:e034::1002
Mon Jul 17 14:18:43 2017 us=16827 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:44 2017 us=108829 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:44 2017 us=842030 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:44 2017 us=873231 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:45 2017 us=122831 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:45 2017 us=122831 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:46 2017 us=994834 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:47 2017 us=135235 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:47 2017 us=135235 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:47 2017 us=915236 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:47 2017 us=946436 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:51 2017 us=35241 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:51 2017 us=144442 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:51 2017 us=253642 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:52 2017 us=49243 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:53 2017 us=593646 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:53 2017 us=749646 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:54 2017 us=61647 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:54 2017 us=607648 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:54 2017 us=763648 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:56 2017 us=620051 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:56 2017 us=776051 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:18:58 2017 us=70854 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:00 2017 us=629258 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:00 2017 us=629258 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:00 2017 us=644858 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:00 2017 us=785258 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:00 2017 us=894459 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:01 2017 us=643260 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:01 2017 us=643260 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:01 2017 us=658860 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:02 2017 us=657262 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:02 2017 us=657262 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:03 2017 us=390463 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:03 2017 us=671264 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:04 2017 us=404465 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:04 2017 us=669665 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:04 2017 us=669665 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:06 2017 us=73668 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:06 2017 us=416868 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:07 2017 us=680471 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:07 2017 us=680471 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:07 2017 us=696071 Recursive routing detected, drop tun packet to [AF_INET]222.222.97.13:1194
Mon Jul 17 14:19:07 2017 us=914471 TCP/UDP: Closing socket
Mon Jul 17 14:19:07 2017 us=914471 C:\Windows\system32\route.exe DELETE 10.200.0.1 MASK 255.255.255.255 10.200.0.13
Mon Jul 17 14:19:07 2017 us=914471 Route deletion via service succeeded
Mon Jul 17 14:19:07 2017 us=914471 C:\Windows\system32\route.exe DELETE 222.222.97.13 MASK 255.255.255.255 111.111.135.254
Mon Jul 17 14:19:07 2017 us=914471 Warning: route gateway is ambiguous: 111.111.135.254 (2 matches)
Mon Jul 17 14:19:07 2017 us=914471 Route deletion via service failed
Mon Jul 17 14:19:07 2017 us=914471 C:\Windows\system32\route.exe DELETE 0.0.0.0 MASK 128.0.0.0 10.200.0.13
Mon Jul 17 14:19:07 2017 us=930071 Route deletion via service succeeded
Mon Jul 17 14:19:07 2017 us=930071 C:\Windows\system32\route.exe DELETE 128.0.0.0 MASK 128.0.0.0 10.200.0.13
Mon Jul 17 14:19:07 2017 us=930071 Route deletion via service succeeded
Mon Jul 17 14:19:07 2017 us=930071 Closing TUN/TAP interface
Mon Jul 17 14:19:07 2017 us=961271 TAP: DHCP address released
Mon Jul 17 14:19:07 2017 us=961271 SIGTERM[hard,] received, process exiting
Mon Jul 17 14:19:07 2017 us=961271 MANAGEMENT: >STATE:1500293947,EXITING,SIGTERM,,,,,
WRWWRWRWRWRWWRRWRWWRRWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrrWrrWrrWrrWrWrrrWrrWrWrrrWrrWrRrWrrWrrWrrWrrWrrWrrWrrWrrWrrWrrWrrWrRrWrWrrrWrrWrrWrrWrWrrrWrrWrWrrrWrrWrrWrrWrWrrrWrrWrrWrWrrrWr

client
proto udp
remote vpnserver
port 1194
dev tun
nobind

remote-cert-tls server
ca digicert.pem

pkcs11-providers eTPkcs11.dll
pkcs11-id 'SafeNet\x2C\x20Inc\x2E/eToken/00a3659c/Jan\x20Just/36343132443132424330433945434336' pkcs11-cert-private 1

verb 5

comp-lzo
redirect-gateway def1

Hi,

This indeed is a regression, or a "non-handled special case in the iservice" (waking up Selva and Heiko).

2.3 is calling route.exe, which seems to just handle this case fine ("the given gateway address is present on two different interfaces", which I find ambiguous myself :-) ).

2.4 in your setup is using the interactive service...

... which notices that the gateway is ambiguous and refuses to cooperate.

Without checking the code, there's a few things here that are not good

- that openvpn just goes ahead, while it "should" know that adding the "def1" default routes afterwards is going to make things explode
- that we fail, instead of just installing the route (with warning) - which could either be "just pick an interface and log that" or "just pick no interface at all, and let windows routing figure this out"

Now *this* is actually good news :-) - instead of blowing up your CPU, we notice that we're stuck and log that.

As a workaround, what you might do instead...

- connect over IPv6 - the IPv6 code is different and I'm curious what it will do :-)

- use "--ip-win32 ipapi" (+ run gui as admin) to avoid using the interactive service

gert

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

When this was reported I had made a patch to handle this, somehow forgot to send it in. Or could be that I was not totally happy with it (or not tested). Anyway,
the next email has the patch as I have it -- will do any cleanup if needed provided
it looks sensible.

Selva

From: Selva Nair <[email protected]...>

Currently a route addition using IPAPI or service is skipped if the route gateway is reachable by multiple interfaces. This changes that to use the interface with lowest metric.

Reported by Jan Just Keijser <[email protected]...>

---
 src/openvpn/route.c |  3 +--
 src/openvpn/tun.c   | 14 ++++++++++++--
 2 files changed, 13 insertions(+), 4 deletions(-)

index 8c71e6e..3937018 100644
@@ -2729,7 +2729,7 @@ get_default_gateway(struct route_gateway_info *rgi)
         if (rgi->gateway.addr)
         {
             rgi->flags |= RGI_ADDR_DEFINED;
-            a_index = adapter_index_of_ip(adapters, rgi->gateway.addr, NULL, &rgi->gateway.netmask);
+            a_index = dwForwardIfIndex;
             if (a_index != TUN_ADAPTER_INDEX_INVALID)
             {
                 rgi->adapter_index = a_index;

@@ -2780,7 +2780,6 @@ windows_route_find_if_index(const struct route_ipv4 *r, const struct tuntap *tt)
         msg(M_WARN, "Warning: route gateway is ambiguous: %s (%d matches)",
             print_in_addr_t(r->gateway, 0, &gc),
             count);
-        ret = TUN_ADAPTER_INDEX_INVALID;
     }
 
     dmsg(D_ROUTE_DEBUG, "DEBUG: route find if: on_tun=%d count=%d index=%d",

index 3639718..d0461ef 100644
@@ -45,6 +45,7 @@
 #include "manage.h"
 #include "route.h"
 #include "win32.h"
+#include "block_dns.h"
 
 #include "memdbg.h"
 

@@ -4483,6 +4484,7 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
     struct gc_arena gc = gc_new();
     DWORD ret = TUN_ADAPTER_INDEX_INVALID;
     in_addr_t highest_netmask = 0;
+    int lowest_metric = INT_MAX;
     bool first = true;
 
     if (count)

@@ -4496,9 +4498,11 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
 
         if (is_ip_in_adapter_subnet(list, ip, &hn))
         {
+            int metric = get_interface_metric(list->Index, AF_INET);
             if (first || hn > highest_netmask)
             {
                 highest_netmask = hn;
+                lowest_metric = metric;
                 if (count)
                 {
                     *count = 1;

@@ -4512,16 +4516,22 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
                 {
                     ++*count;
                 }
+                if (metric < lowest_metric)
+                {
+                    ret = list->Index;
+                    lowest_metric = metric;
+                }
             }
         }
         list = list->Next;
     }
 
-    dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d",
+    dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d metric=%d",
          print_in_addr_t(ip, 0, &gc),
          print_in_addr_t(highest_netmask, 0, &gc),
          (int)ret,
-         count ? *count : -1);
+         count ? *count : -1,
+         metric);
 
     if (ret == TUN_ADAPTER_INDEX_INVALID && count)
     {

2.1.4

From: Selva Nair <[email protected]...>

Currently a route addition using IPAPI or service is skipped if the route gateway is reachable by multiple interfaces. This changes that to use the interface with lowest metric. Implemented by

(i) Do not over-write the return value with TUN_ADAPTER_INDEX_INVALID in windows_route_find_if_index() if multiple interfaces match a route.
(ii) Select the interface with lowest metric in adapter_index_of_ip()
instead of the first one found when multiple interfaces match.

Reported by Jan Just Keijser <[email protected]...>

v2: - A private get_interface_metric() method and better error reporting
- Revert an unintented edit of route.c (a_index = ...)
- Improve the commit message

---
 src/openvpn/route.c |  1 -
 src/openvpn/tun.c   | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 57 insertions(+), 3 deletions(-)

index 8c71e6e..66a8ae3 100644
@@ -2780,7 +2780,6 @@ windows_route_find_if_index(const struct route_ipv4 *r, const struct tuntap *tt)
         msg(M_WARN, "Warning: route gateway is ambiguous: %s (%d matches)",
             print_in_addr_t(r->gateway, 0, &gc),
             count);
-        ret = TUN_ADAPTER_INDEX_INVALID;
     }
 
     dmsg(D_ROUTE_DEBUG, "DEBUG: route find if: on_tun=%d count=%d index=%d",

2.1.4

2017-11-06 6:14 GMT+05:00 <[email protected]...>:

..

2015 may sound old, but we are targeting ubuntu 16.04 which has mingw 3.1.0 from mid 2014.

Selva

From: Selva Nair <[email protected]...>

Currently a route addition using IPAPI or service is skipped if the route gateway is reachable by multiple interfaces. This changes that to use the interface with lowest metric. Implemented by

(i) Do not over-write the return value with TUN_ADAPTER_INDEX_INVALID in windows_route_find_if_index() if multiple interfaces match a route.
(ii) Select the interface with lowest metric in adapter_index_of_ip()
instead of the first one found when multiple interfaces match.

Reported by Jan Just Keijser <[email protected]...>

---
NOTE: depends on https://patchwork.openvpn.net/patch/136/

v3: Simpliyfy the patch using get_interface_metric from block_dns.c
Simpler is also easier to review :)
(requires patch 136 https://patchwork.openvpn.net/patch/136/)
v2:
- Revert an unintented edit of route.c (a_index = ...)
- Improve the commit message

 src/openvpn/route.c |  1 -
 src/openvpn/tun.c   | 17 +++++++++++++++--
 2 files changed, 15 insertions(+), 3 deletions(-)

index f121d3f..218ca96 100644
@@ -2785,7 +2785,6 @@ windows_route_find_if_index(const struct route_ipv4 *r, const struct tuntap *tt)
         msg(M_WARN, "Warning: route gateway is ambiguous: %s (%d matches)",
             print_in_addr_t(r->gateway, 0, &gc),
             count);
-        ret = TUN_ADAPTER_INDEX_INVALID;
     }
 
     dmsg(D_ROUTE_DEBUG, "DEBUG: route find if: on_tun=%d count=%d index=%d",

index 2644d99..f424f82 100644
@@ -45,6 +45,7 @@
 #include "manage.h"
 #include "route.h"
 #include "win32.h"
+#include "block_dns.h"
 
 #include "memdbg.h"
 

@@ -4480,6 +4481,7 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
     struct gc_arena gc = gc_new();
     DWORD ret = TUN_ADAPTER_INDEX_INVALID;
     in_addr_t highest_netmask = 0;
+    int lowest_metric = INT_MAX;
     bool first = true;
 
     if (count)

@@ -4493,9 +4495,14 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
 
         if (is_ip_in_adapter_subnet(list, ip, &hn))
         {
+            int metric = get_interface_metric(list->Index, AF_INET, NULL);
             if (first || hn > highest_netmask)
             {
                 highest_netmask = hn;
+                if (metric >= 0)
+                {
+                    lowest_metric = metric;
+                }
                 if (count)
                 {
                     *count = 1;

@@ -4509,16 +4516,22 @@ adapter_index_of_ip(const IP_ADAPTER_INFO *list,
                 {
                     ++*count;
                 }
+                if (metric >= 0 && metric < lowest_metric)
+                {
+                    ret = list->Index;
+                    lowest_metric = metric;
+                }
             }
         }
         list = list->Next;
     }
 
-    dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d",
+    dmsg(D_ROUTE_DEBUG, "DEBUG: IP Locate: ip=%s nm=%s index=%d count=%d metric=%d",
          print_in_addr_t(ip, 0, &gc),
          print_in_addr_t(highest_netmask, 0, &gc),
          (int)ret,
-         count ? *count : -1);
+         count ? *count : -1,
+         lowest_metric);
 
     if (ret == TUN_ADAPTER_INDEX_INVALID && count)
     {

2.1.4

Works as expected.

the patch works as expected but I did notice something in the openvpn log :

Fri Jan 26 14:08:09 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=1
Fri Jan 26 14:08:10 2018 NETSH: C:\Windows\system32\netsh.exe interface ipv6 set address interface=17 2001:610:120::200:0:1001 store=active Fri Jan 26 14:08:10 2018 add_route_ipv6(2001:610:120::200:0:0/112 -> 2001:610:120::200:0:1001 metric 0) dev vpn0
Fri Jan 26 14:08:10 2018 C:\Windows\system32\netsh.exe interface ipv6 add route 2001:610:120::200:0:0/112 interface=17 fe80::8 store=active Fri Jan 26 14:08:10 2018 env_block: add PATH=C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem

the route was added with the default GW of fe80::8 : should I be worried ?
Note that this also happened with the regular 2.4.4 version of OpenVPN and also note that the TAP adapter on my Win7 laptop is named 'vpn0'

JJK

arrrgh, the important line is missing:
 ERROR: Windows route add ipv6 command failed: returned error code 1

sorry for the noise,

JJK

Hi,

Gert has explained the fe80::8 magic.

Here is my guess about the ERROR: The route already existed and so errored trying to add again -- most likely from a previous run as it seems we have a problem in deleting the route on exit (I guess this is on Windows 10) (see Trac 1003:
https://community.openvpn.net/openvpn/ticket/1003 )

"netsh int ipv6 show route" will confirm that.

The route destinations have their host bits zeroed out before setting route, but those bits reappear (which is strange) in route delete. And netsh doesnt like that at least on Windows 10. Gert, any idea why this happens?

Selva

Hi Selva,

this is on *Windows 7*  and indeed that route is never deleted when OpenVPN exits. Here's the error associated with *that*:

Fri Jan 26 16:13:08 2018 ERROR: Windows route delete ipv6 command failed: returned error code 1
Fri Jan 26 16:13:09 2018 NETSH: C:\Windows\system32\netsh.exe interface ipv6 delete address vpn0 2001:610:120::200:0:1001 store=active Fri Jan 26 16:13:09 2018 TAP: DHCP address released

C:\Users\janjust\OpenVPN\config> C:\Windows\system32\netsh.exe interface ipv6 delete route 2001:610:120::200:0:1001/112 interface=17 fe80::8 store=active
The parameter is incorrect.

HTH,

JJK

Hi,

...

The error is due to the host part (1001) in the route destination -- changing that to
C:\Windows\system32\netsh.exe interface ipv6 delete route 2001:610:120::200:0:/112
should succeed.

The mystery (at least for me) is where that host part is coming from... Its zeroed out before setting the route, and I thought the same (?) route list pointer is
passed in while deleting routes.

Selva

Hi,

that also did not work; what does work is:
  C:\Windows\system32\netsh.exe interface ipv6 delete route 2001:610:120::200:0:0/112

so indeed, the host part is added at deletion time.

HTH,

JJK

Hi,

"I seem to remember code changes related to that, possibly related to the introduction of the interactive service handle"

Can't look right now, but I think we had 2x zeroing and that was unified and stored, or something like that... need to check, later this evening.

gert

now what should I write here...

Gert Doering - Munich, Germany                             [email protected]...

Hi,

So. Staring a bit at the code (while sf.net is refusing to forward my last mail to patchwork... so I can't go ahead and commit & close more patches).

The clearing of the route happens in

route.c: route_ipv6_clear_host_bits()

which is only called from add_route_ipv6().

route_ipv6_clear_host_bits() does clear the "call by reference" route_ipv6 structure, though, so it really should bubble up the call chain to add_routes(), zeroeing out the bits in the "rl6->routes_ipv6" IPv6 route list.

Testing this on linux with "--route-ipv6 2001:db8::1234:abcd/112" I can see that this seems to work correctly...

Tue Feb 20 15:19:02 2018 add_route_ipv6(2001:db8::1234:0/112 -> fd00:abcd:194:4::1 metric -1) dev tap3 Tue Feb 20 15:19:02 2018 /bin/route -A inet6 add 2001:db8::1234:0/112 dev tap3 gw fd00:abcd:194:4::1

Tue Feb 20 15:19:15 2018 delete_route_ipv6(2001:db8::1234:0/112)
Tue Feb 20 15:19:15 2018 /bin/route -A inet6 del 2001:db8::1234:0/112 dev tap3 gw fd00:abcd:194:4::1

(just grabbing a random test config, "tap" has no significance here, works the same with "tun")

"master" behaves the same here as release/2.4.

Re-reading the thread, I can now see where this is coming from - this is not "normal routes" but "on-link interface routes", and this is something that got broken on introducing the iservice (where the zeroeing of the host bits was changed from "zap the local copy" to "zap the upstream copy, and do not zap it in delete_route() again, because, not needed") - commit a24dd2e31.

The on-link route is installed by tun.c:add_route_connected_v6_net(), which operates on a on-stack instance of "struct route_ipv6"...

void
add_route_connected_v6_net(struct tuntap *tt,
const struct env_set *es)

{
    struct route_ipv6 r6;

    CLEAR(r6);
    r6.network = tt->local_ipv6;
    r6.netbits = tt->netbits_ipv6;
    r6.gateway = tt->local_ipv6;
    r6.metric  = 0;                     /* connected route */
    r6.flags   = RT_DEFINED | RT_METRIC_DEFINED;
    add_route_ipv6(&r6, tt, 0, es);
}

... so the zero'ing in add_route_ipv6() does not "stick".

On termination, we call delete_route_connected_v6_net(), which sets up a new "route_ipv6" copy... with all bits set.

Jan Just, could you please test the following patch? This will explicitly clear the host bits for the "on-link" route again.

Fully untested :-)

gert

index ebb15bd3..79453665 100644
@@ -839,6 +839,7 @@ delete_route_connected_v6_net(struct tuntap *tt,
     r6.gateway = tt->local_ipv6;
     r6.metric  = 0;                     /* connected route */
     r6.flags   = RT_DEFINED | RT_ADDED | RT_METRIC_DEFINED;
+    route_ipv6_clear_host_bits(&r6);
     delete_route_ipv6(&r6, tt, 0, es);
 }
 #endif /* if defined(_WIN32) || defined(TARGET_DARWIN) || defined(TARGET_NETBSD) || defined(TARGET_OPENBSD) */

now what should I write here...

Gert Doering - Munich, Germany                             [email protected]...

Hi,

And indeed, it does not link, because route_ipv6_clear_host_bits() isn't exported from route.c

A proper patch that is actually compiling and has been tested on Win7 will be coming soon (in a new thread, so patchwork can properly pick it up).

Win7 seems to ignore the extra host bits on route removal, so I cannot "see" the actual *error* - but I can see whether or not the netsh.exe invocation is correct, which is good enough to test whether the fix is working.

gert

now what should I write here...

Gert Doering - Munich, Germany                             [email protected]...

Hi,

fe80::8 is our/my tun-over-tap hack.

On "proper" tun devices, there is no ARP or IPv6 neighbour discovery, so you can point routes toward the *interface* - or towards "an IP address that the system knows is on the tun interface" (which we do for IPv4, because that's how it was coded in the dark ages). Since there is no ARP, "a route towards tun" leads to "packet sent to tun fd, no further processing, let openvpn deal with it". Easy.

On TAP there is "ethernet underneath", so for each route destination, an ARP or IPv6 neighbour discovery lookup needs to be done, and then the packet is sent towards that MAC address. Also fairly easy, since OpenVPN only deals with MAC address forwarding and lets the OSes on both sides sort out the L2 discovery.

Now, tun-on-windows is "tun" as far as OpenVPN is concerned, and "TAP" as far as Windows is concerned - so there needs to be an explicitely named gateway address (v4 as v6), and ARP / IPv6 ND. Since OpenVPN doesn't deal with MAC stuff here, magic happens in the Windows tap driver - namely, if Windows sends an ARP request for "the ipv4 route gateway", the TAP driver answers it (openvpn tells it via ioctl() what the gateway address is, so the TAP driver knows what addresses to listen for). For IPv6, we have link-local, so I did not bother to implement a new ioctl() and logic on the OpenVPN side, but always set the next-hop route to "fe80::8" - and the tap driver knows "oh, this is magic, answer the ND query".

Long story short:
- for tap interfaces in tun mode, fe80::8 is what you want to see.
- For tap interfaces in *tap* mode, "a real IPv6 address of the gateway on the other end" is what you want (ND goes back and forth over OpenVPN/tap layer).

- LAN routes (/128 bypass routes to the VPN server, for example) should never use fe80::8 but the real link-local or global address of the gateway -> now with "it works if you have two interfaces!" :-)

- your log file looks like it should :-)

gert

now what should I write here...

Gert Doering - Munich, Germany                             [email protected]...

Based on JJK's test results, staring at the code, understanding the intent :-) and test compilation on 16.04.

Your patch has been applied to the master and release/2.4 branch.

TODO: figuring out what's wrong with the IPv6 route "host bits", but that's totally outside these code paths, it just came up in this thread.

commit 3854d4040e0d6fd2a58292e8bb1c1fbae5c17bb1 (master) commit 965c7906f61e6de30adc1cc2d24ec73e345e0007 (release/2.4)

Author: Selva Nair
Date:   Wed Jan 24 12:31:45 2018 -0500

     Use lowest metric interface when multiple interfaces match a route

     Signed-off-by: Selva Nair <[email protected]...>
     Acked-by: Gert Doering <[email protected]...>
     Message-Id: <[email protected]...>
     URL: https://www.mail-archive.com/[email protected]/msg16347.html
     Signed-off-by: Gert Doering <[email protected]...>

--
kind regards,

Gert Doering

Hi,

And the rationale for the patch:

As in the logs,

Mon Jul 17 14:18:43 2017 us=1227 C:\Windows\system32\route.exe ADD 222.222.97.13 MASK 255.255.255.255 111.111.135.254
Mon Jul 17 14:18:43 2017 us=1227 Warning: route gateway is ambiguous:
111.111.135.254 (2 matches)

when multiple interfaces match a route, we bail out with a warning unless the route method used is exe. This code is the same in 2.3.17 and 2.4.3 except the latter defaults to using IPAPI invoked via the service. 2.3.7 also defaults to IPAPI but falls back to exe if the former fails.

Looking the sources: In tun.c
adapter_index_of_ip() returns the index of the first matching adapter and the number of matching adapters found. If the count is > 1 windows_route_find_if_index() in route.c sets the index to TUN_ADAPTER_INDEX_INVALID and route addition gets aborted.

We could slightly modify adapter_index_of_ip() to return the matching index with smallest metric when more than one are found.

Selva

Please include the pkcs11-helper patch from
https://github.com/OpenSC/pkcs11-helper/pull/4 to make it support using RFC7512 PKCS#11 URIs to specify certificates/keys instead of its own non-standard identifiers.

(It still accepts the old form, for compatibility).

2017-07-17 17:07 GMT+05:00 David Woodhouse <[email protected]...>:

openvpn is split into several repo, we have pkcs11-helper at least here:

https://github.com/OpenVPN/openvpn-build/blob/master/generic/build.vars#L12

and here:

https://github.com/OpenVPN/openvpn/blob/master/.travis/build-deps.sh#L38

it is not trivial to maintain distro + patch (while openvpn-build does include a "patch" folder).

thoughts?

I released the new Windows installer but without this patch. That said, the patch/PR you linked to makes sense. Does the patch have an active maintainer? If yes, then I propose is that we

- Fork OpenSC/pkcs11-helper to OpenVPN/pkcs11-helper
- Apply the patch to our fork
- Produce and publish our own pkcs11-helper tarballs
- Point openvpn-build to our tarballs
- Periodically rebase our fork with upstream

Thoughts?

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

2017-07-25 21:53 GMT+05:00 Samuli Seppänen <[email protected]...>:

well, I think we should unify build events across all projects. i.e. openvpn should be built the same way no matter who builds (openvpn itself, openvpn-build, travis ci or whatever).

that said, I think such build events should go to openvpn's Makefile. and we will need to update things in the single place (currently - a lot of places).

another idea is to rework the patch and merge it into the main fork.

Hi,

NAK. OpenVPN's Makefile does not care where pkcs11-helper is coming from - it expects something proper to be installed in the build environment. It's not OpenVPN's job to figure out where to get stuff from - this is why we have openvpn-build for "complicated" cases.

gert

USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             [email protected]...
fax: +49-89-35655025                        [email protected]...

That would be me, I suppose. Until/unless the upstream maintainer applies the patch, I or someone else will continue to maintain the patch in the Fedora package at least.

Well, there's always the option of ditching pkcs11-helper entirely... :)

Hi David, other,

It seems that my "I'm using my phone, sorry for top posting" went far beyond that because I also forgot to add the list as a recipient.

So, here is my message (minus the top-posting) sent to David only (sorry David)

To which David replied (hope you don't mind if I quote you):

(I think I'm already using this patch, so thanks you David for your work).

A single patch would not a a problem for distro maintainers, but subsequent/future changes in the forked repository might introduce other, less compatible changes in the library, leading to two versions of the same library, with maybe the same ABI and the same name -- and that worries me a bit (not that much, but I also maintain a fork of lede for my own purpose, and I'm not sure I'd like to deal with such complexity :)). Aviding that would require a library name change and I'm not sure it's a good thing at all.

And you also have to take into account weird people like me who also add their own changes into various libraries or binaries to suit their needs (the whole "hey, it's free software, I can change it" thing). Pointing them to a fork is not going to work well IMHO. It would be better if the maintainer finally decide to either implement the required change or merge your patch to the library.

Best regards,

-- Emmanuel Deloget

Don't Do That Then. :)

It's one thing to have a simple patch which makes it accept the RFC compliant identifiers that the upstream maintainer is being weirdly recalcitrant about, without changing the API/ABI at all.

To add other things to a "fork"... or really even to consider it a fork... would be silly.

People who build from source can already merge the fix into their pkcs11-helper or not as they see fit; this conversation was about the *binaries* being provided. AFAIK the only binary being provided for pkcs11-helper is on Windows; there are Ubuntu binaries but if they have PKCS#11 support they'll be using the system's version of pkcs11-helper. (Which probably also lacks the patch; I have rarely seen any sign of anyone in Debian/Ubuntu caring about doing the right thing w.r.t. any crypto-related stuff, unfortunately.)

Well yes, that's true. But it's more likely that I'll finally get round to porting OpenVPN to something other than pkcs11-helper before that happens, unfortunately.

On 26/07/17 10:02, David Woodhouse wrote:
[...snip...]

TL;DR: If you or anyone else have a chance to look into this, we will appreciate that effort enormously! Just grab us on ML or the #openvpn-devel IRC channel (FreeNode) and we can discuss it further.

Steffan and I discussed what is needed to be done to port p11-kit awhile ago; we're also not too happy about the pkcs11-helper dependency. If we had only had support for one SSL library, it probably would have been somewhat simpler. But as we strive hard to have both mbed TLS and OpenSSL builds to be fairly feature comparable (from an OpenVPN perspective), this gets a bit more challenging.

IIRC, one of the more challenging parts here is to get p11-kit to play nicely along with mbed TLS. We are concerned that there are some need to also adopt mbed TLS to support p11-kit. However, I quite recently heard some rumours that mbed TLS provides some API for offloading sign and decrypt operations outside of the library; that needs to be investigated further and to consider if this is a better way for the integration.

kind regards,

David Sommerseth
OpenVPN Technologies, Inc

Yeah... in my Copious Spare Time I have also been looking at integrating PKCS#11 support as a first-class citizen into OpenSSL. You really ought to be able to just pass a PKCS#11 URI instead of a filename into fairly much any API and have it Just Work.

But implementing the basic crypto primitives in libp11-kit might be interesting, which makes it easier to wrap them for various crypto libraries.

2017-07-17 17:07 GMT+05:00 David Woodhouse <[email protected]...>:

David, can you have a look, please ?

https://github.com/OpenVPN/openvpn-build/pull/110

I added this as a topic for today's meeting, with links to earlier discussion. It seems we agreed that patching the 2.4 Windows installers would be fine.

Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock