Giter Club home page Giter Club logo

tunnelkit's Introduction

iOS 15+ macOS 12+ tvOS 17+ License GPLv3

Unit Tests Release

TunnelKit

This library provides a generic framework for VPN development on Apple platforms.

OpenVPN

TunnelKit comes with a simplified Swift/Obj-C implementation of the OpenVPN® protocol, whose crypto layer is built on top of OpenSSL 3.2.0.

The client is known to work with OpenVPN® 2.3+ servers.

  • Handshake and tunneling over UDP or TCP
  • Ciphers
    • AES-CBC (128/192/256 bit)
    • AES-GCM (128/192/256 bit, 2.4)
  • HMAC digests
    • SHA-1
    • SHA-2 (224/256/384/512 bit)
  • NCP (Negotiable Crypto Parameters, 2.4)
    • Server-side
  • TLS handshake
    • Server validation (CA, EKU)
    • Client certificate
  • TLS wrapping
    • Authentication (--tls-auth)
    • Encryption (--tls-crypt)
  • Compression framing
    • Via --comp-lzo (deprecated in 2.4)
    • Via --compress
  • Compression algorithms
    • LZO (via --comp-lzo or --compress lzo)
  • Key renegotiation
  • Replay protection (hardcoded window)

The library therefore supports compression framing, just not newer compression. Remember to match server-side compression and framing, otherwise the client will shut down with an error. E.g. if server has comp-lzo no, client must use compressionFraming = .compLZO.

Support for .ovpn configuration

TunnelKit can parse .ovpn configuration files. Below are a few details worth mentioning.

Non-standard

  • XOR-patch functionality:
    • Multi-byte XOR Masking
      • Via --scramble xormask <passphrase>
      • XOR all incoming and outgoing bytes by the passphrase given
    • XOR Position Masking
      • Via --scramble xorptrpos
      • XOR all bytes by their position in the array
    • Packet Reverse Scramble
      • Via --scramble reverse
      • Keeps the first byte and reverses the rest of the array
    • XOR Scramble Obfuscate
      • Via --scramble obfuscate <passphrase>
      • Performs a combination of the three above (specifically xormask <passphrase> -> xorptrpos -> reverse -> xorptrpos for reading, and the opposite for writing)
    • See Tunnelblick website for more details (Patch was written in accordance with Tunnelblick's patch for compatibility)

Unsupported

  • UDP fragmentation, i.e. --fragment
  • Compression via --compress other than empty or lzo
  • Connecting via proxy
  • External file references (inline <block> only)
  • Static key encryption (non-TLS)
  • <connection> blocks
  • net_gateway literals in routes

Ignored

  • Some MTU overrides
    • --link-mtu and variants
    • --mssfix
  • Multiple --remote with different host values (first wins)
  • Static client-side routes

Many other flags are ignored too but it's normally not an issue.

WireGuard

TunnelKit offers a user-friendly API to the modern WireGuard® protocol.

Manual Xcode steps

If you add any TunnelKitWireGuard* Swift package to the "Link with binary libraries" section of your app or tunnel extension, you are bound to hit this error:

ld: library not found for -lwg-go

because part of the WireGuardKit package is based on make, which SwiftPM doesn't support yet.

Therefore, make sure to follow the steps below for proper integration:

  • Copy Scripts/build_wireguard_go_bridge.sh somewhere in your project.
  • In Xcode, click File -> New -> Target. Switch to "Other" tab and choose "External Build System".
  • Type a name for your target.
  • Open the "Info" tab and replace /usr/bin/make with $(PROJECT_DIR)/path/to/build_wireguard_go_bridge.sh in "Build Tool".
  • Switch to "Build Settings" and find SDKROOT. Type in macosx if you target macOS, or type in iphoneos if you target iOS.
  • Locate your tunnel extension target and switch to "Build Phases" tab.
  • Locate "Dependencies" section and hit "+" to add the target you have just created.
  • Repeat the process for each platform.

Installation

Requirements

  • iOS 15+ / macOS 12+ / tvOS 17+
  • SwiftPM 5.3
  • Git (preinstalled with Xcode Command Line Tools)
  • golang (for WireGuardKit)

It's highly recommended to use the Git package provided by Homebrew.

Caveats

Make sure to set "Enable Bitcode" (iOS) to NO, otherwise the library would not be able to link OpenSSL (OpenVPN) and the wg-go bridge (WireGuard).

Recent versions of Xcode (latest is 13.1) have an issue where the "Frameworks" directory is replicated inside application extensions. This is not a blocker during development, but will prevent your archive from being validated against App Store Connect due to the following error:

ERROR ITMS-90206: "Invalid Bundle. The bundle at '*.appex' contains disallowed file 'Frameworks'."

You will need to add a "Run Script" phase to your main app target where you manually remove the offending folder, i.e.:

rm -rf "${BUILT_PRODUCTS_DIR}/${PLUGINS_FOLDER_PATH}/YourTunnelTarget.appex/Frameworks"

for iOS and:

rm -rf "${BUILT_PRODUCTS_DIR}/${PLUGINS_FOLDER_PATH}/YourTunnelTarget.appex/Contents/Frameworks"

for macOS.

Demo

Download the library codebase locally:

$ git clone https://github.com/passepartoutvpn/tunnelkit.git

There are demo targets containing a simple app for testing the tunnels. Open Demo/TunnelKit.xcodeproject in Xcode and run it.

For the VPN to work properly, the demo requires:

  • App Groups and Keychain Sharing capabilities
  • App IDs with Packet Tunnel entitlements

both in the main app and the tunnel extension targets.

In order to test connectivity in your own environment, modify the file Demo/Demo/Configuration.swift to match your VPN server parameters.

Example:

private let ca = CryptoContainer(pem: """
-----BEGIN CERTIFICATE-----
MIIFJDCC...
-----END CERTIFICATE-----
""")

Make sure to also update the following constants in the *ViewController.swift files, according to your developer account and your target bundle identifiers:

private let appGroup = "..."
private let tunnelIdentifier = "..."

Remember that the App Group on macOS requires a team ID prefix.

Documentation

The library is split into several modules, in order to decouple the low-level protocol implementation from the platform-specific bridging, namely the NetworkExtension VPN framework.

Full documentation of the public interface is available and can be generated by opening the package in Xcode and running "Build Documentation" (Xcode 13).

TunnelKit

This component includes convenient classes to control the VPN tunnel from your app without the NetworkExtension headaches. Have a look at VPN implementations:

  • MockVPN (default, useful to test on simulator)
  • NetworkExtensionVPN (anything based on NetworkExtension)

TunnelKitOpenVPN

Provides the entities to interact with the OpenVPN tunnel.

TunnelKitOpenVPNAppExtension

Contains the NEPacketTunnelProvider implementation of a OpenVPN tunnel.

TunnelKitWireGuard

Provides the entities to interact with the WireGuard tunnel.

TunnelKitWireGuardAppExtension

Contains the NEPacketTunnelProvider implementation of a WireGuard tunnel.

License

Copyright (c) 2024 Davide De Rosa. All rights reserved.

Part I

This project is licensed under the GPLv3.

Part II

As seen in libsignal-protocol-c:

Additional Permissions For Submission to Apple App Store: Provided that you are otherwise in compliance with the GPLv3 for each covered work you convey (including without limitation making the Corresponding Source available in compliance with Section 6 of the GPLv3), the Author also grants you the additional permission to convey through the Apple App Store non-source executable versions of the Program as incorporated into each applicable covered work as Executable Versions only under the Mozilla Public License version 2.0 (https://www.mozilla.org/en-US/MPL/2.0/).

Part III

Part I and II do not apply to the LZO library, which remains licensed under the terms of the GPLv2+.

Contributing

By contributing to this project you are agreeing to the terms stated in the Contributor License Agreement (CLA).

For more details please see CONTRIBUTING.

Other licenses

A custom TunnelKit license, e.g. for use in proprietary software, may be negotiated on request.

Credits

  • lzo - Copyright (c) 1996-2017 Markus F.X.J. Oberhumer
  • PIATunnel - Copyright (c) 2018-Present Private Internet Access
  • SURFnet
  • SwiftyBeaver - Copyright (c) 2015 Sebastian Kreutzberger
  • XMB5 for the XOR patch - Copyright (c) 2020 Sam Foxman
  • tmthecoder for the complete XOR patch - Copyright (c) 2022 Tejas Mehta
  • eduVPN for the convenient WireGuardKitGo script

OpenVPN

© Copyright 2022 OpenVPN | OpenVPN is a registered trademark of OpenVPN, Inc.

WireGuard

© Copyright 2015-2022 Jason A. Donenfeld. All Rights Reserved. "WireGuard" and the "WireGuard" logo are registered trademarks of Jason A. Donenfeld.

OpenSSL

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (https://www.openssl.org/)

Contacts

Twitter: @keeshux

Website: passepartoutvpn.app

tunnelkit's People

Contributors

jaroslavas avatar jleal52 avatar johankool avatar johnyezub avatar keeshux avatar pahnev avatar roop avatar thinkchaos avatar tmthecoder avatar ueshiba avatar xmb5 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

tunnelkit's Issues

Incomplete PUSH_REPLY with SoftEther

Not a regression, but PUSH_REPLY is incomplete when parsed. The result is that e.g. IPv4 settings are not found, thus resulting in VPN connected but no VPN icon (i.e. no tunnel).

When we try to connect, get error

Summary

Hi,
When we try to connect, get this error
ERROR SessionProxy.doShutdown():1162 - Trigger shutdown (error: Error Domain=TunnelKitNative Code=207 "(null)")

My ovpn file

# Automatically generated OpenVPN client config file
# Generated on Mon Jan 28 14:53:22 2019 by vps608033

# Default Cipher
cipher AES-256-CBC
# Note: this config file contains inline private keys
#       and therefore should be kept confidential!
# Note: this configuration is user-locked to the username below
# OVPN_ACCESS_SERVER_USERNAME=oguz
# Define the profile name of this particular configuration file
# [email protected]
# OVPN_ACCESS_SERVER_CLI_PREF_ALLOW_WEB_IMPORT=True
# OVPN_ACCESS_SERVER_CLI_PREF_BASIC_CLIENT=False
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_CONNECT=True
# OVPN_ACCESS_SERVER_CLI_PREF_ENABLE_XD_PROXY=True
# OVPN_ACCESS_SERVER_WSHOST=54.37.71.97:1194
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_START
# -----BEGIN CERTIFICATE-----
 [Lines that appear to be security-related have been omitted]
# -----END CERTIFICATE-----
# OVPN_ACCESS_SERVER_WEB_CA_BUNDLE_STOP
# OVPN_ACCESS_SERVER_IS_OPENVPN_WEB_CA=1
# OVPN_ACCESS_SERVER_ORGANIZATION=OpenVPN, Inc.
setenv FORWARD_COMPATIBLE 1
client
server-poll-timeout 4
nobind
remote 54.37.71.97 1194 udp
remote 54.37.71.97 1194 udp
remote 54.37.71.97 1194 tcp
remote 54.37.71.97 1194 udp
remote 54.37.71.97 1194 udp
remote 54.37.71.97 1194 udp
remote 54.37.71.97 1194 udp
remote 54.37.71.97 1194 udp
dev tun
dev-type tun
ns-cert-type server
setenv opt tls-version-min 1.0 or-highest
reneg-sec 604800
sndbuf 100000
rcvbuf 100000
auth-user-pass
# NOTE: LZO commands are pushed by the Access Server at connect time.
# NOTE: The below line doesn't disable LZO.
comp-lzo no
verb 3
setenv PUSH_PEER_INFO

<ca>
 [Security-related line(s) omitted]
</ca>

<cert>
 [Security-related line(s) omitted]
</cert>

<key>
 [Security-related line(s) omitted]
</key>

key-direction 1
<tls-auth>
 [Security-related line(s) omitted]
</tls-auth>

## -----BEGIN RSA SIGNATURE-----
 [Lines that appear to be security-related have been omitted]
## -----END RSA SIGNATURE-----
## -----BEGIN CERTIFICATE-----
 [Lines that appear to be security-related have been omitted]
## -----END CERTIFICATE-----
## -----BEGIN CERTIFICATE-----
 [Lines that appear to be security-related have been omitted]
## -----END CERTIFICATE-----

My Code

 private func makeProtocol() -> NETunnelProviderProtocol {
        let credentials = SessionProxy.Credentials("oguz","password")
        let ssss = try! ConfigurationParser.parsed(fromURL:  URL(string: "https://burakakdeniz.com.tr/client.ovpn")!)
        var builder = TunnelKitProvider.ConfigurationBuilder(sessionConfiguration: ssss.configuration)
        builder.endpointProtocols = [EndpointProtocol(.udp, ssss.protocols[0].port)]
        builder.mtu = 1250
        builder.shouldDebug = true
        builder.debugLogKey = "Log"
        
        let hostname = ssss.hostname
        let configuration = builder.build()
        return try! configuration.generatedTunnelProtocol(
            withBundleIdentifier: ViewController.bundleIdentifier,
            appGroup: ViewController.appGroup,
            hostname: hostname,
            credentials: credentials
        )
    }

CA is always required for OpenVPN client

https://github.com/keeshux/tunnelkit/blob/d0a46fe20e536571ea83625f8ef6437fa53161f2/TunnelKit/Sources/Core/TLSBox.m#L118

The official OpenVPN client requires a CA to be set in the client configuration file. Without setting a CA the OpenVPN client gives an error and refuses to even try to connect.

  1. The CA certificate MUST be always set in the client configuration, no reason to have an if for this;
  2. The server certificate sent by the VPN server when establishing the TLS channel MUST be verified to be signed by this CA.

The VPN disconnects after a few seconds

Summary

The VPN disconnects after a few seconds.

Steps to reproduce

Use this config file https://gist.github.com/timotei-cliqz/960d3b8d05b23fa77d09a3ce3652dc70
Relevant info here:
ConnectionInfo(username: "something", password: "something", hostname: "3.120.33.136", port: 1194, socketType: .udp, CA: SeeConfig, compression: .compLZO, cipher: .aes128cbc, digest: .sha1)
Server uses a version of OpenVPN above 2.3.

What is the current bug behavior?

The VPN disconnects after a few seconds.

Relevant logs and/or screenshots

https://gist.github.com/timotei-cliqz/f8a4da1481b3d855f6b499ef0a46bda6
End of the logs:

2018-10-18 15:31:57.867 INFO TunnelKitProvider.sessionDidStart():503 - Tunnel interface is now UP
2018-10-18 15:31:57.982 ERROR SessionProxy.doShutdown():1058 - Trigger shutdown (error: Error Domain=TunnelKitNative Code=103 "(null)")
2018-10-18 15:31:57.983 INFO TunnelKitProvider.sessionDidStop():514 - Session did stop
2018-10-18 15:31:57.983 DEBUG NETCPInterface.observeValueInTunnelQueue():143 - Socket state is cancelled (endpoint: 108.61.242.60:443 -> in progress)
2018-10-18 15:31:57.984 INFO SessionProxy.cleanup():299 - Cleaning up...
2018-10-18 15:31:57.985 ERROR TunnelKitProvider.finishTunnelDisconnection():342 - Tunnel did stop (error: Error Domain=TunnelKitNative Code=103 "(null)")
2018-10-18 15:31:57.985 DEBUG TunnelKitProvider.flushLog():594 - Flushing log...

OpenSSL-Apple problem after pod install

Summary

When adding pod 'TunnelKit' to my pod file and afterwards running pod install either the process enters an infinite sleep/grep loop or throws xcrun: error: SDK "iphoneos" cannot be located

Steps to reproduce

run pod install

What is the current bug behavior?

enters an infinite sleep/grep loop or throws xcrun: error: SDK "iphoneos" cannot be located

What is the expected correct behavior?

should install tunnelkit

Relevant logs and/or screenshots

Possible fixes suggested remediation

Unable to create release build

Summary

Get a error for release builds in the device logs "DYLD, Library not loaded: openssl.dylib, Reason: unsafe use of relative rpath openssl.dylib"

Steps to reproduce

Create a release build with the Demo project and install on device.

What is the current bug behavior?

App does not want to start.

What is the expected correct behavior?

App works like debug builds

Relevant logs and/or screenshots

Possible fixes suggested remediation

Unable to connect with client.ovpn file in demo project(status is 3)

Screenshot 2019-03-13 at 11 23 55 AM

@keeshux Hello Sir,
I am trying to connect vpn with .ovpn file and unable to use ConfigurationParser class to parse client.ovpn file in demo project. For this I create extension in view controller class -

extension ViewController {
private static let bundleIdentifier = "it.****.VPNProject.VPNProjectTunnel"

private func makeProtocol() -> NETunnelProviderProtocol {

guard let configurationFileURL = Bundle.main.url(forResource: "client", withExtension: "ovpn"),
    let configurationFileContent = try? Data(contentsOf: configurationFileURL)
    else {
        fatalError()
}

let tunnelProtocol = NETunnelProviderProtocol()
tunnelProtocol.serverAddress = "32.46.32.239"
tunnelProtocol.providerBundleIdentifier = ViewController.bundleIdentifier
tunnelProtocol.providerConfiguration = ["ovpn": configurationFileContent]
return tunnelProtocol

}
}

and by using this I am getting this response :-
VPNStatusDidChange: 2
VPNStatusDidChange: 2
VPNStatusDidChange: 2
VPNStatusDidChange: 3
VPNStatusDidChange: 3
VPNStatusDidChange: 3 (what is mean of status 1,2,3,4,5 ?)

then in updateButton() method .connected case is called. But in device no vpn icon is shown and also my ip address is not changed.I am using physical device iPhone6 plus and 8 plus, not an simulator.

I didn't understand what to do now. Please help me
Also I want to know how can I use configurationParser class to parse client.ovpn file in view controller.From the documentation it not easy to understand the steps.

Unable to connect through DEMO project's.

Summary

Steps to reproduce

  1. Download all files
  2. Pod install
  3. Change Project's Capabilities as ReadMe.md mentioned.
  4. Run
  5. Change nothing and click Connect on device.

What is the current bug behavior?

Crash.
image

What is the expected correct behavior?

Connect Successfully


Is the demo server not work and must connect to my vpn server by editing the CA and user infos?

'SIOCGIFMTU failed' after some network changes

Summary

After succesfully creating a VPN Tunnel with your library, it crashes after some network changes (WiFi to 4G and back).

Steps to reproduce

Connect to WiFi and create a Tunnel, then disable Wifi and let 4G take over the connection. Wait until the Tunnel reconnects succesfully and enable WiFi. Then, wait again for the reconnection and repeat the process until the connection is down.

What is the current bug behavior?

The connection crashes in one of the reconnections (it might be the 50th try or the 10th, looks random) for some reason and the Tunnel is not active anymore.

What is the expected correct behavior?

The Tunnel stays active like it does with every other reconnection before the bug

Relevant logs and/or screenshots

We get this error in the device log when the bug happens:

SIOCGIFMTU failed: Device not configured NEVirtualInterfaceAdjustReadBufferSize: interface_get_mtu failed (6), defaulting to max mtu

Our .ovpn file looks like this (Some info is erased, to maintain our client's privacy)

client
remote xxx.xxxxxxx.xxx xxx udp
nobind
dev tun
persist-tun
persist-key
verify-x509-name xxx.xxxxxxx.xxx name
remote-cert-tls server
cipher AES-128-CBC

<ca>
-----BEGIN CERTIFICATE-----
....
(certificate content)
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
....
(certificate content)
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
....
(certificate content)
....
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
....
(certificate content)
....
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
....
(certificate content)
....
-----END PRIVATE KEY-----
</key>

Possible fixes suggested remediation

I kind of went around this issue by enabling on demand mode on my NETunnelProviderManager, with manager.onDemandRules = [OnDemandRuleConnect()], wich works for our app desired functionality and reestablishes the tunnel after it crashes.

Another bug arised when I fixed it this way, but I will describe it in another issue.

Thanks in advance

Server Return Error

Dear
when i connect with my own server i get following error.
OpenSSL: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, client-instance restarting

i have copy a working CA from .opvn file in to ViewController.swift

Not working over Wifi

Summary

I am using your Lib to create VPN Application and I can not make it work over Wifi. 4G is working fine

UDP may disconnect on high-speed upload link

Summary

UDP socket runs out of memory on sustained writes.

Steps to reproduce

Start a high speed upload like a speed test.

What is the current bug behavior?

Tunnel may disconnect.

What is the expected correct behavior?

Tunnel should not disconnect.

Relevant logs and/or screenshots

16:30:30 - Data: Failed LINK write during send data: Error Domain=NSPOSIXErrorDomain Code=55 "No buffer space available"
16:30:30 - Trigger shutdown (error: failedLinkWrite)
16:30:30 - Session did stop
16:30:30 - Failed LINK read: Error Domain=NSPOSIXErrorDomain Code=89 "Operation canceled"
16:30:30 - Socket state is cancelled (endpoint: #9dbef9646b868342# -> #7deccb0813af8907#)
16:30:30 - Cleaning up...
16:30:30 - Tunnel did stop (error: failedLinkWrite)
16:30:30 - Flushing log...

Possible fixes suggested remediation

On such error (code?), delay the writes a little bit and retry. Or drop the packets completely i.e. ignore the error.

After automatic changes in Connection, the tunnel is ignored

Summary

After fixing my issue in iOS with on demand mode (described in other issue #59), we tested how it reconnects after automatic changes (going in and out of the WiFi zone and letting 4G take over and back), and in some cases, the traffic would not go over the tunnel until we went back to the last connection (We know this because our vpn blocks certain websites, and they are visible in this instances).

Event after waiting for the tunnel to reasert after the change ocurs, the problem persists.

This also happens when leaving the device idle for a long time, after using it again, the connection reasserts, and sometimes it doesnt go thorught the tunnel correctly, the only solution is reactivating the VPN manually or waiting for it to become active again.

We know its not a server issue, the config file works in OpenVPN Connect for iOS and other platforms.

Steps to reproduce

  1. Start the Tunnel and move in an out of the WiFi range automaticly (If you do it from the device settings, it will not happen) while testing the VPN connection (in our case, trying to access a restricted page).

  2. Start the tunnel and leave the device idle. Unlock the device after some time passes (10 ~15 min) so the connection has to reassert itself, test the VPN connection.

What is the current bug behavior?

We can access pages that the VPN blocks, even after the tunnel reconnects when the connection changes

What is the expected correct behavior?

When the tunnel reconnects, we shouldn't be able to access restricted pages (OpenVPN iOS acomplishes this every time).

Relevant logs and/or screenshots

Nothing in the logs, but here is our configuration file (Some info is erased, to maintain our client's privacy)

client
remote xxx.xxxxxxx.xxx xxx udp
nobind
dev tun
persist-tun
persist-key
verify-x509-name xxx.xxxxxxx.xxx name
remote-cert-tls server
cipher AES-128-CBC

<ca>
-----BEGIN CERTIFICATE-----
....
(certificate content)
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
....
(certificate content)
....
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
....
(certificate content)
....
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
....
(certificate content)
....
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
....
(certificate content)
....
-----END PRIVATE KEY-----
</key>

The only code in our PacketTunnelProvider is this:

override func setTunnelNetworkSettings(_ tunnelNetworkSettings: NETunnelNetworkSettings?, completionHandler: ((Error?) -> Void)? = nil)
{
	tunnelNetworkSettings?.dnsSettings?.matchDomains = [""];
	
	(tunnelNetworkSettings as! NEPacketTunnelNetworkSettings).ipv4Settings?.includedRoutes?.remove(at: 0);

	
	super.setTunnelNetworkSettings(tunnelNetworkSettings, completionHandler: completionHandler)
}

Possible fixes suggested remediation

Encrypted keys in .ovpn (PKCS#1)

Could take passphrase as a parameter to ConfigurationParser.parsed().

Single passphrase or dictionary (paranoid)? E.g.:

{
    "key": "..."
}
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,1C7216F89C74E56260FE71A9C1BAB35E

VPN DNS is unreachable when VPN is not default gateway

This ovpn profile used in Passepartout (1.5.0/1.6.0 b1779) successfully allows me to access my home's LAN DNS server while on cellular. Attempts to connect to websites show up as successfully forwarded in my DNS server logs, but do not resolve.

I am not able to compile with xcode 10.1

Summary

I am receiving bench of errors and can't compile

Steps to reproduce

Just open with xcode version 10.1 and swift 5

What is the current bug behavior?

What is the expected correct behavior?

Relevant logs and/or screenshots

image

Possible fixes suggested remediation

Last disconnect error for BasicTunnel-macOS changed from "none" to "The VPN session failed because an internal error occurred."

Summary

I tried to connect to open vpn from Demo project and got some issues
Could somebody help me or explain what i do wrong. Thanks!

I created app id's for both of BasicTunnel-macOS and BasicTunnelExtension-macOS
Configured app groups: $(TeamIdentifierPrefix)group.io.bbapps.uvpn.macosapp.rc, $(TeamIdentifierPrefix)group.io.bbapps.uvpn.macosapp.rc.BasicTunnel.BasicTunnelExtension with "Network Extensions" and "Personal VPN" capabilities.

Also I use .ovpn file to configure connection.

Relevant logs and/or screenshots

In xcode logs I got only this:
xcode log

And when I tried to use Console I got this:
console log
console log1
https://ibb.co/xFtvK9r
https://ibb.co/JKwHW3K

I'm really bad in OpenVPN. Probably I forgot to configure something.
I'm very glad if you will help me

Prevent MITM with a VPN client cert pretending to be VPN server

Summary

Extended Key Usage check MUST be implemented;

What is the current bug behavior?

Clients can impersonate a VPN server.

What is the expected correct behavior?

Clients can not impersonate a VPN server.

Possible fixes suggested remediation

Implement the OpenVPN option --remote-cert-tls client:

       --remote-cert-tls client|server
              Require  that  peer  certificate was signed with an explicit key
              usage and extended key usage based on RFC3280 TLS rules.

              This is a useful security option for clients, to ensure that the
              host  they  connect to is a designated server.  Or the other way
              around; for a server to verify that only  hosts  with  a  client
              certificate can connect.

              The   --remote-cert-tls   client   option   is   equivalent   to
              --remote-cert-ku --remote-cert-eku "TLS Web  Client  Authentica‐
              tion"

              The   --remote-cert-tls   server   option   is   equivalent   to
              --remote-cert-ku --remote-cert-eku "TLS Web  Server  Authentica‐
              tion"

              This  is  an  important security precaution to protect against a
              man-in-the-middle attack where an authorized client attempts  to
              connect  to  another  client  by  impersonating the server.  The
              attack is easily prevented by having clients verify  the  server
              certificate   using   any   one   of  --remote-cert-tls,  --ver‐
              ify-x509-name, or --tls-verify.

Unable to request logs (Unexpectedly found nil while unwrapping an Optional value)

Summary

I'm trying the example iOS project provided in this repo with my own OpenVPN server, but the connection didn't work and when i'm trying to display logs to get more details i'm getting crash because of Unexpectedly found nil while unwrapping an Optional value.

Steps to reproduce

Using demo project into real iPhone 6 (iOS 11) device, taping "Connect" and then "See log".

What is the current bug behavior?

It seem that the data variable can't be unwrapped due to his nil value, here: https://github.com/keeshux/tunnelkit/blob/master/Demo/BasicTunnel-iOS/ViewController.swift#L222

What is the expected correct behavior?

Relevant logs and/or screenshots

Capture d’écran 2019-04-27 à 20 49 27

Possible fixes suggested remediation

Possible issue in Demo App

Summary

Hi keeshux, i am getting issue and not sure it's related to tunnelkit or not. After launching Demo App and trying to fill everything (manually). When i want to start VPN i am getting Update Required in VPN Profiles (for IOS 12)

Steps to reproduce

Try to add any OpenVPN details in IOS 12

What is the current bug behavior?

What is the expected correct behavior?

Should be starting without problems

Relevant logs and/or screenshots

Possible fixes suggested remediation

XOR Patch Feature

Summary

One useful feature that can be added to OpenVPN is the scramble xor patch (github). It XORs all bytes sent by openvpn, evading firewalls. It would be a great addition to passepartout that would make it stand out from the official iOS OpenVPN app, and it should be relatively simple to implement.

Original reddit post

Some servers might send mixed DATA_V1 / DATA_V2 packets

Mullvad pushes a peer-id then sends DATA_V1 packets (?). The current code can't handle a mix of the two types. The effect is an abrupt disconnection due to a decryption error (103), because the packet has an unexpected format.

Allow runtime adjusting of CoreConfiguration parameters.

Summary

It would be convenient for our use case to allow unmasked private data in some cased.

Steps to reproduce

Run ay app with TunnelKit and inspect logging produced by the network extension.

Possible fixes suggested remediation

Make this and other values variable instead of let constants.
In our case this is the related let constant: https://github.com/keeshux/tunnelkit/blob/650f0d54563250f8d87ad9f5c015bbfccdbe5892/TunnelKit/Sources/Core/CoreConfiguration.swift#L63

Client certificate may fail for unclear reasons

Some users are experiencing TunnelKitError 205 with client certificate authentication. Not sure if it's related to encrypted private keys. Need to debug OpenSSL response in more detail.

Packet authentication failure with tls-auth

Cannot connect to vpn with ovpn file. I use ConfigurationParser class to parse client.ovpn file and it can parse this file. However, connection cannot be established. Logs are below when try to establish connection :

2019-02-01 11:47:30.795 INFO TunnelKitProvider.startTunnel():179 - Starting tunnel...
2019-02-01 11:47:30.817 INFO TunnelKitProvider+Configuration.print():459 - Protocols: [TCP:1198]
2019-02-01 11:47:30.817 INFO TunnelKitProvider+Configuration.print():460 - Cipher: AES-256-CBC
2019-02-01 11:47:30.817 INFO TunnelKitProvider+Configuration.print():461 - Digest: HMAC-SHA1
2019-02-01 11:47:30.817 INFO TunnelKitProvider+Configuration.print():465 - Client verification: disabled
2019-02-01 11:47:30.817 INFO TunnelKitProvider+Configuration.print():467 - MTU: 1350
2019-02-01 11:47:30.818 INFO TunnelKitProvider+Configuration.print():468 - Compression framing: comp-lzo
2019-02-01 11:47:30.818 INFO TunnelKitProvider+Configuration.print():472 - Keep-alive: never
2019-02-01 11:47:30.818 INFO TunnelKitProvider+Configuration.print():477 - Renegotiation: never
2019-02-01 11:47:30.819 INFO TunnelKitProvider+Configuration.print():480 - TLS wrapping: auth
2019-02-01 11:47:30.819 INFO TunnelKitProvider+Configuration.print():484 - Debug: true

2019-02-01 11:47:31.132 ERROR SessionProxy.loopLink():419 - Failed LINK read: Error Domain=NSPOSIXErrorDomain Code=57 "Socket is not connected"

2019-02-01 11:47:31.209 ERROR TunnelKitProvider.finishTunnelDisconnection():296 - Tunnel did stop (error: linkError)

Server errors are below :

Thu Jan 31 16:53:11 2019 TCP connection established with [AF_INET]xxx.xx.xxx.xx:xxxx
Thu Jan 31 16:53:11 2019 xxx.xx.xxx.xx:xxxx TLS: Initial packet from [AF_INET]xxx.xx.xxx.xx:xxxx, sid=3b85a451 fe3ffe6a
Thu Jan 31 16:53:12 2019 xxx.xx.xxx.xx:xxxx Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #12 / time = (1548942796) Thu Jan 31 $
Thu Jan 31 16:53:12 2019 xxx.xx.xxx.xx:xxxxTLS Error: incoming packet authentication failed from [AF_INET]xxx.xx.xxx.xx:xxxx
Thu Jan 31 16:53:12 2019 xxx.xx.xxx.xx:xxxx Fatal TLS error (check_tls_errors_co), restarting
Thu Jan 31 16:53:12 2019 xxx.xx.xxx.xx:xxxx SIGUSR1[soft,tls-error] received, client-instance restarting

implement explicit-exit-notify

       --explicit-exit-notify [n]
              In UDP client mode or point-to-point mode, send  server/peer  an
              exit  notification  if tunnel is restarted or OpenVPN process is
              exited.  In client mode, on exit/restart, this option will  tell
              the  server  to  immediately  close  its  client instance object
              rather than waiting for a timeout.  The n parameter  (default=1)
              controls the maximum number of attempts that the client will try
              to resend the exit notification message.

              In UDP server mode, send RESTART control channel command to con‐
              nected  clients.  The  n  parameter  (default=1) controls client
              behavior. With n = 1 client will attempt  to  reconnect  to  the
              same server, with n = 2 client will advance to the next server.

              OpenVPN  will not send any exit notifications unless this option
              is enabled.

This option can be pushed to the client by the server. The server can also send the notification to the client in case the server restarts or shuts down.

--remote-random not respected (?)

Small Note

I think this is the best place to create this issue, but it could possibly be a Passepartout issue.

Summary

I realize that the tunnelkit README.md states that multiple --remote’s with different host values are ignored, but then #76 has a fix that is supposed to respect --remote-random, which is why I’m creating this issue– Passepartout (which utilizes tunnelkit) seems to only use the first --remote, even if --remote-random is specified.

Steps to reproduce

(These steps are applicable to Passepartout)

  1. Import a .ovpn file that includes multiple --remote’s and specifies --remote-random at the beginning of the file
  2. Check the "Endpoint" option under the "Configuration" category in Passepartout; only the first --remote host is listed
  3. Enable the VPN
  4. Check the debug log; the first remote is used, even if you try re-connecting the VPN

What is the current bug behavior?

--remote-random is not respected

What is the expected correct behavior?

--remote-random is meant to work

Relevant logs and/or screenshots

19:27:31 - Starting tunnel...
19:27:31 - App version: Passepartout 1.6.1 (1870)
19:27:31 - 	Protocols: [UDP:1301]
19:27:31 - 	Cipher: AES-256-CBC
19:27:31 - 	Digest: HMAC-SHA1
19:27:31 - 	Compression framing: disabled
19:27:31 - 	Compression algorithm: disabled
19:27:31 - 	Client verification: disabled
19:27:31 - 	TLS wrapping: disabled
19:27:31 - 	TLS security level: 0
19:27:31 - 	Keep-alive: 10.0 seconds
19:27:31 - 	Renegotiation: never
19:27:31 - 	Server EKU verification: enabled
19:27:31 - 	Randomize endpoint: true
19:27:31 - 	Gateway: ["IPv6", "IPv4"]
19:27:31 - 	DNS: not configured
19:27:31 - 	MTU: 1250
19:27:31 - 	Debug: true
19:27:31 - 	Masks private data: false
19:27:31 - Current SSID: none (disconnected from WiFi)
19:27:31 - Creating link session
19:27:31 - DNS resolve hostname: 185.232.22.66
19:27:31 - DNS resolved addresses: ["185.232.22.66"]
19:27:31 - Will connect to 185.232.22.66:1301
19:27:31 - Socket type is NEUDPSocket
19:27:31 - Socket state is ready (endpoint: 185.232.22.66:1301 -> 185.232.22.66:1301)
19:27:31 - Starting VPN session
19:27:31 - Send hard reset
19:27:31 - Negotiation key index is 0
19:27:31 - Control: Enqueued 1 packet [0]
19:27:31 - Control: Write control packet {HARD_RESET_CLIENT_V2 | 0, sid: b4e2df8b791131c3, pid: 0, [0 bytes]}
19:27:31 - Send control packet (14 bytes): 38b4e2df8b791131c30000000000
19:27:31 - Control: Try read packet with code HARD_RESET_SERVER_V2 and key 0
19:27:31 - Control: Read packet {HARD_RESET_SERVER_V2 | 0, sid: 872fbe56e2beadd7, acks: {[0], b4e2df8b791131c3}, pid: 0}
19:27:31 - Send ack for received packetId 0
19:27:31 - Control: Write ack packet {ACK_V1 | 0, sid: b4e2df8b791131c3, acks: {[0], 872fbe56e2beadd7}}
19:27:31 - Control: Remote sessionId is 872fbe56e2beadd7
19:27:31 - Start TLS handshake
19:27:31 - TLS.connect: Pulled ciphertext (176 bytes)
19:27:31 - Control: Enqueued 1 packet [1]
19:27:31 - Control: Write control packet {CONTROL_V1 | 0, sid: b4e2df8b791131c3, pid: 1, [176 bytes]}
19:27:31 - Send control packet (190 bytes): 20b4e2df8b791131c3000000000116030100ab010000a7030320b7e8ebec91a70d4c062219986a872d69137eeffe1148cf2aa9afc3ebf33661000038c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f00ff01000046000b000403000102000a000a0008001d001700190018002300000016000000170000000d0020001e060106020603050105020503040104020403030103020303020102020203
19:27:31 - Ack successfully written to LINK for packetId 0
19:27:31 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:31 - Control: Read packet {CONTROL_V1 | 0, sid: 872fbe56e2beadd7, acks: {[1], b4e2df8b791131c3}, pid: 1, [1174 bytes]}
19:27:31 - Send ack for received packetId 1
19:27:31 - Control: Write ack packet {ACK_V1 | 0, sid: b4e2df8b791131c3, acks: {[1], 872fbe56e2beadd7}}
19:27:31 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:31 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:31 - Control: Read packet {CONTROL_V1 | 0, sid: 872fbe56e2beadd7, pid: 2, [1174 bytes]}
19:27:31 - Send ack for received packetId 2
19:27:31 - Control: Write ack packet {ACK_V1 | 0, sid: b4e2df8b791131c3, acks: {[2], 872fbe56e2beadd7}}
19:27:31 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:31 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:31 - Control: Read packet {CONTROL_V1 | 0, sid: 872fbe56e2beadd7, pid: 3, [1174 bytes]}
19:27:31 - Send ack for received packetId 3
19:27:31 - Control: Write ack packet {ACK_V1 | 0, sid: b4e2df8b791131c3, acks: {[3], 872fbe56e2beadd7}}
19:27:31 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:31 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:31 - Control: Read packet {CONTROL_V1 | 0, sid: 872fbe56e2beadd7, pid: 4, [1174 bytes]}
19:27:31 - Send ack for received packetId 4
19:27:31 - Control: Write ack packet {ACK_V1 | 0, sid: b4e2df8b791131c3, acks: {[4], 872fbe56e2beadd7}}
19:27:31 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:31 - Ack successfully written to LINK for packetId 1
19:27:31 - Ack successfully written to LINK for packetId 2
19:27:31 - Ack successfully written to LINK for packetId 3
19:27:31 - Ack successfully written to LINK for packetId 4
19:27:31 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:31 - Control: Read packet {CONTROL_V1 | 0, sid: 872fbe56e2beadd7, pid: 5, [1174 bytes]}
19:27:31 - Send ack for received packetId 5
19:27:31 - Control: Write ack packet {ACK_V1 | 0, sid: b4e2df8b791131c3, acks: {[5], 872fbe56e2beadd7}}
19:27:31 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:31 - TLS.connect: Send pulled ciphertext (7 bytes)
19:27:31 - Control: Enqueued 1 packet [2]
19:27:31 - Control: Write control packet {CONTROL_V1 | 0, sid: b4e2df8b791131c3, pid: 2, [7 bytes]}
19:27:31 - Send control packet (21 bytes): 20b4e2df8b791131c3000000000215030300020230
19:27:31 - Ack successfully written to LINK for packetId 5
19:27:31 - Trigger shutdown (error: Error Domain=TunnelKitNative Code=201 "(null)")
19:27:31 - Session did stop
19:27:31 - Socket state is cancelled (endpoint: 185.232.22.66:1301 -> 185.232.22.66:1301)
19:27:31 - Cleaning up...
19:27:31 - Tunnel did stop (error: Error Domain=TunnelKitNative Code=201 "(null)")
19:27:31 - Flushing log...

--- EOF ---

19:27:31 - Starting tunnel...
19:27:31 - App version: Passepartout 1.6.1 (1870)
19:27:31 - 	Protocols: [UDP:1301]
19:27:31 - 	Cipher: AES-256-CBC
19:27:31 - 	Digest: HMAC-SHA1
19:27:31 - 	Compression framing: disabled
19:27:31 - 	Compression algorithm: disabled
19:27:31 - 	Client verification: disabled
19:27:31 - 	TLS wrapping: disabled
19:27:31 - 	TLS security level: 0
19:27:31 - 	Keep-alive: 10.0 seconds
19:27:31 - 	Renegotiation: never
19:27:31 - 	Server EKU verification: enabled
19:27:31 - 	Randomize endpoint: true
19:27:31 - 	Gateway: ["IPv6", "IPv4"]
19:27:31 - 	DNS: not configured
19:27:31 - 	MTU: 1250
19:27:31 - 	Debug: true
19:27:31 - 	Masks private data: false
19:27:31 - Current SSID: none (disconnected from WiFi)
19:27:31 - Creating link session
19:27:31 - DNS resolve hostname: 185.232.22.66
19:27:31 - DNS resolved addresses: ["185.232.22.66"]
19:27:31 - Will connect to 185.232.22.66:1301
19:27:31 - Socket type is NEUDPSocket
19:27:31 - Socket state is ready (endpoint: 185.232.22.66:1301 -> 185.232.22.66:1301)
19:27:31 - Starting VPN session
19:27:31 - Send hard reset
19:27:31 - Negotiation key index is 0
19:27:31 - Control: Enqueued 1 packet [0]
19:27:31 - Control: Write control packet {HARD_RESET_CLIENT_V2 | 0, sid: fea1f3a454287853, pid: 0, [0 bytes]}
19:27:31 - Send control packet (14 bytes): 38fea1f3a4542878530000000000
19:27:31 - Control: Try read packet with code HARD_RESET_SERVER_V2 and key 0
19:27:31 - Control: Read packet {HARD_RESET_SERVER_V2 | 0, sid: 3851cce453fae4ea, acks: {[0], fea1f3a454287853}, pid: 0}
19:27:31 - Send ack for received packetId 0
19:27:31 - Control: Write ack packet {ACK_V1 | 0, sid: fea1f3a454287853, acks: {[0], 3851cce453fae4ea}}
19:27:31 - Control: Remote sessionId is 3851cce453fae4ea
19:27:31 - Start TLS handshake
19:27:31 - TLS.connect: Pulled ciphertext (176 bytes)
19:27:31 - Control: Enqueued 1 packet [1]
19:27:31 - Control: Write control packet {CONTROL_V1 | 0, sid: fea1f3a454287853, pid: 1, [176 bytes]}
19:27:31 - Send control packet (190 bytes): 20fea1f3a454287853000000000116030100ab010000a70303df7737792f71c95a8108da6b0f8d39a38b1c4c113b5ca3834306e36fad21a7e7000038c02cc030009fcca9cca8ccaac02bc02f009ec024c028006bc023c0270067c00ac0140039c009c0130033009d009c003d003c0035002f00ff01000046000b000403000102000a000a0008001d001700190018002300000016000000170000000d0020001e060106020603050105020503040104020403030103020303020102020203
19:27:31 - Ack successfully written to LINK for packetId 0
19:27:32 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:32 - Control: Read packet {CONTROL_V1 | 0, sid: 3851cce453fae4ea, acks: {[1], fea1f3a454287853}, pid: 1, [1174 bytes]}
19:27:32 - Send ack for received packetId 1
19:27:32 - Control: Write ack packet {ACK_V1 | 0, sid: fea1f3a454287853, acks: {[1], 3851cce453fae4ea}}
19:27:32 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:32 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:32 - Control: Read packet {CONTROL_V1 | 0, sid: 3851cce453fae4ea, pid: 2, [1174 bytes]}
19:27:32 - Send ack for received packetId 2
19:27:32 - Control: Write ack packet {ACK_V1 | 0, sid: fea1f3a454287853, acks: {[2], 3851cce453fae4ea}}
19:27:32 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:32 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:32 - Control: Read packet {CONTROL_V1 | 0, sid: 3851cce453fae4ea, pid: 3, [1174 bytes]}
19:27:32 - Send ack for received packetId 3
19:27:32 - Control: Write ack packet {ACK_V1 | 0, sid: fea1f3a454287853, acks: {[3], 3851cce453fae4ea}}
19:27:32 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:32 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:32 - Control: Read packet {CONTROL_V1 | 0, sid: 3851cce453fae4ea, pid: 4, [1174 bytes]}
19:27:32 - Send ack for received packetId 4
19:27:32 - Control: Write ack packet {ACK_V1 | 0, sid: fea1f3a454287853, acks: {[4], 3851cce453fae4ea}}
19:27:32 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:32 - Ack successfully written to LINK for packetId 1
19:27:32 - Ack successfully written to LINK for packetId 2
19:27:32 - Ack successfully written to LINK for packetId 3
19:27:32 - Ack successfully written to LINK for packetId 4
19:27:32 - Control: Try read packet with code CONTROL_V1 and key 0
19:27:32 - Control: Read packet {CONTROL_V1 | 0, sid: 3851cce453fae4ea, pid: 5, [1174 bytes]}
19:27:32 - Send ack for received packetId 5
19:27:32 - Control: Write ack packet {ACK_V1 | 0, sid: fea1f3a454287853, acks: {[5], 3851cce453fae4ea}}
19:27:32 - TLS.connect: Put received ciphertext (1174 bytes)
19:27:32 - TLS.connect: Send pulled ciphertext (7 bytes)
19:27:32 - Control: Enqueued 1 packet [2]
19:27:32 - Control: Write control packet {CONTROL_V1 | 0, sid: fea1f3a454287853, pid: 2, [7 bytes]}
19:27:32 - Send control packet (21 bytes): 20fea1f3a454287853000000000215030300020230
19:27:32 - Ack successfully written to LINK for packetId 5
19:27:32 - Trigger shutdown (error: Error Domain=TunnelKitNative Code=201 "(null)")
19:27:32 - Session did stop
19:27:32 - Socket state is cancelled (endpoint: 185.232.22.66:1301 -> 185.232.22.66:1301)
19:27:32 - Cleaning up...
19:27:32 - Tunnel did stop (error: Error Domain=TunnelKitNative Code=201 "(null)")
19:27:32 - Flushing log...

Additional Info

The OpenVPN server I was connecting to (as shown in the log file) was failing its TLS handshake and Passepartout would retry connecting to it (which was the first --remote in the .ovpn file). I removed the erroneous --remote from the .ovpn file and re-added it, yet the first --remote would still be used when connecting the VPN.

Possible fixes/suggested remediation

Kindly support --remote-random if it already isn’t; thanks for making this app btw (it’s much more reliable than OpenVPN Connect) :)

Bad encapsulated packet length from peer (2989)

Summary

When trying to connect to the OpenVPN server running on my ASUS RT-AC86U router (running Asuswrt-Merlin 384.7 firmware) in Passepartout for iOS the status changes from "Connecting" to "Inactive", with this error message:

WARNING: Bad encapsulated packet length from peer (2989), which must be > 0 and <= 1626 -- please ensure that --tun-mtu or --link-mtu is equal on both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]

Steps to reproduce

  1. Export .ovpn profile (attached below) from router interface
  2. Import profile in Passepartout
  3. Select new host
  4. Tap "Use this profile"

What is the current bug behavior?

Unable to connect iPhone/iPad to VPN provided by router.

What is the expected correct behavior?

Successful connection to VPN provided by router on iPhone/iPad.

Note that the same profile works fine when using OpenVPN Connect instead of Passepartout.

Relevant logs and/or screenshots

Server (router) log:

TCP connection established with [AF_INET]<IP address of iPhone>:443
<IP address of iPhone>:<port> TLS: Initial packet from [AF_INET]<IP address of iPhone>:443, sid=<redacted> <redacted>
<IP address of iPhone>:<port> WARNING: Bad encapsulated packet length from peer (2989), which must be > 0 and <= 1626 -- please ensure that both peers -- this condition could also indicate a possible active attack on the TCP link -- [Attempting restart...]
<IP address of iPhone>:<port> Connection reset, restarting [0]
<IP address of iPhone>:<port> SIGUSR1[soft,connection-reset] received, client-instance restarting

Client (iPhone) log:

App: Passepartout 1.0 (1040)
OS: iOS 12.0.1
Device: iPhone

11:24:27 - Starting tunnel...
11:24:27 - App version: Passepartout 1.0 (1040)
11:24:27 - 	Protocols: [TCP:443]
11:24:27 - 	Cipher: AES-128-CBC
11:24:27 - 	Digest: HMAC-SHA1
11:24:27 - 	Client verification: enabled
11:24:27 - 	MTU: 1250
11:24:27 - 	Compression framing: disabled
11:24:27 - 	Keep-alive: never
11:24:27 - 	Renegotiation: never
11:24:27 - 	TLS wrapping: disabled
11:24:27 - 	Debug: true
11:24:27 - Current SSID: none (disconnected from WiFi)
11:24:27 - Creating link session
11:24:27 - DNS resolve hostname: <hostname of router>
11:24:27 - DNS resolved addresses: ["<IP address of router>"]
11:24:27 - Will connect to <IP address of router>:443
11:24:27 - Socket type is NETCPSocket
11:24:27 - Socket state is connecting (endpoint: <IP address of router>:443 -> in progress)
11:24:27 - Socket state is connected (endpoint: <IP address of router>:443 -> <IP address of router>:443)
11:24:27 - Starting VPN session
11:24:27 - Send hard reset
11:24:27 - Negotiation key index is 0
11:24:27 - Control: Enqueued 1 packet [0]
11:24:27 - Control: Write control packet {HARD_RESET_CLIENT_V2 | 0, sid: <redacted>, pid: 0, [0 bytes]}
11:24:27 - Send control packet (14 bytes): <redacted>
11:24:27 - Control: Try read packet with code HARD_RESET_SERVER_V2 and key 0
11:24:27 - Control: Read packet {HARD_RESET_SERVER_V2 | 0, sid: <redacted>, acks: {[0], <redacted>}, pid: 0}
11:24:27 - Send ack for received packetId 0
11:24:27 - Control: Write ack packet {ACK_V1 | 0, sid: <redacted>, acks: {[0], <redacted>}}
11:24:27 - Control: Remote sessionId is <redacted>
11:24:27 - Start TLS handshake
11:24:27 - TLS.connect: Pulled ciphertext (176 bytes)
11:24:27 - Control: Enqueued 1 packet [1]
11:24:27 - Control: Write control packet {CONTROL_V1 | 0, sid: <redacted>, pid: 1, [176 bytes]}
11:24:27 - Send control packet (190 bytes): <redacted>
11:24:27 - Ack successfully written to LINK for packetId 0
11:24:27 - Control: Try read packet with code CONTROL_V1 and key 0
11:24:27 - Control: Read packet {CONTROL_V1 | 0, sid: <redacted>, acks: {[1], <redacted>}, pid: 1, [1170 bytes]}
11:24:27 - Send ack for received packetId 1
11:24:27 - Control: Write ack packet {ACK_V1 | 0, sid: <redacted>, acks: {[1], <redacted>}}
11:24:27 - TLS.connect: Put received ciphertext (1170 bytes)
11:24:27 - Control: Try read packet with code CONTROL_V1 and key 0
11:24:27 - Control: Read packet {CONTROL_V1 | 0, sid: <redacted>, pid: 2, [1170 bytes]}
11:24:27 - Send ack for received packetId 2
11:24:27 - Control: Write ack packet {ACK_V1 | 0, sid: <redacted>, acks: {[2], <redacted>}}
11:24:27 - TLS.connect: Put received ciphertext (1170 bytes)
11:24:27 - Ack successfully written to LINK for packetId 1
11:24:27 - Control: Try read packet with code CONTROL_V1 and key 0
11:24:27 - Control: Read packet {CONTROL_V1 | 0, sid: <redacted>, pid: 3, [889 bytes]}
11:24:27 - Send ack for received packetId 3
11:24:27 - Control: Write ack packet {ACK_V1 | 0, sid: <redacted>, acks: {[3], <redacted>}}
11:24:27 - TLS.connect: Put received ciphertext (889 bytes)
11:24:27 - TLS.connect: Send pulled ciphertext (2975 bytes)
11:24:27 - Control: Enqueued 1 packet [2]
11:24:27 - Control: Write control packet {CONTROL_V1 | 0, sid: <redacted>, pid: 2, [2975 bytes]}
11:24:27 - Send control packet (2989 bytes): <redacted>
11:24:27 - Ack successfully written to LINK for packetId 2
11:24:27 - Ack successfully written to LINK for packetId 3
11:24:27 - Failed LINK read: Error Domain=kNWErrorDomainPOSIX Code=54 "Connection reset by peer" UserInfo={NSDescription=Connection reset by peer}
11:24:27 - Socket state is disconnected (endpoint: <IP address of router>:443 -> <IP address of router>:443)
11:24:27 - Link failures so far: 1 (max = 3)
11:24:27 - Cleaning up...
11:24:27 - Tunnel did stop (error: linkError)
11:24:27 - Flushing log...

Config file (certificates/key not listed):

client
dev tun
proto tcp-client
remote <DNS name for my router> 443
float
ncp-ciphers AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
cipher AES-128-CBC
keepalive 15 60
remote-cert-tls server
resolve-retry infinite
nobind

Server version (on RT-AC86U):

OpenVPN 2.4.6 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct  7 2018
library versions: OpenSSL 1.0.2p  14 Aug 2018, LZO 2.08

Server version (on RT-AC68U, where the same problem occurs):

OpenVPN 2.4.6 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Oct  7 2018
library versions: OpenSSL 1.0.2p  14 Aug 2018, LZO 2.08

Possible fixes suggested remediation

?

DNS is broken when no servers are provided

Not really a bug, but OpenVPN Connect seems to fall back to a working server.

Options:

  • DNS servers for the current network interface
  • A 3rd party server (unlikely)

Unsurprisingly, NEDNSSettings is not smart enough to fall back to system-wide settings when set to nil.

Can't handle multipart PUSH_REPLY

Summary

Steps to reproduce

Push a long list of options (commonly route options) so that the server sends PUSH_REPLY in a multipart fashion with push-continuation 2.

What is the current bug behavior?

Throws .malformedPushReply because it can't always find required options like topology, ifconfig etc.

What is the expected correct behavior?

Handle push-continuation correctly (2 = more to come, 1 = last).

Relevant logs and/or screenshots

Possible fixes suggested remediation

Not able to connect

Hello keeshux perhaps you already know my name from your (github) passepartout issues. Any way I've decided to implement this project since it made more sense. I've managed to compile the demo project. Also have struggled with some issues but could solve them.
That said I ran unto this issue and wanted to consult with you, hopefully you can advice me in some way. Thank you in advance!

Connect button changes to Disconnect but after a few seconds it comes back to Connect.

Xcode logs:
captura de pantalla 2019-02-18 a la s 20 40 32

Mac Console App:
captura de pantalla 2019-02-18 a la s 20 02 11

Can I restrict the running of some software to connect via the OpenVPN configured line?

Summary

Excuse me, I want to ask you a question: Can you restrict certain software connections through OpenVPN configured lines in iOS, while other applications do not connect via OpenVPN configured lines?

Steps to reproduce

What is the current bug behavior?

What is the expected correct behavior?

Relevant logs and/or screenshots

Possible fixes suggested remediation

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.