Re: Wireguard-apple 1.0.16-27 can’t be added via SPM

[Andrej Mihajlov]

Houman,

Great! 

I have added WireguardKitType as a dynamic library which contains all of the 
Swift data types used by WireGuardKit, such as: PrivateKey, PublicKey, 
IPAddressRange, etc.

It does not depend on WireGuardGoBridge, which proved to be problematic to 
include in unit tests (if I recall that right). Apart from that I noticed that 
go runtime spawns some worker threads when binary is linked against wg-go, so 
we didn’t want that in our main bundle or app extensions.

So in short, when using any of data types provided by WireGuardKit:

- Import WireGuardKitTypes in main bundle or app extensions.
- Import WireGuardKit in network extension. Internally WireGuardKit re-exports 
all types from WireGuardKitTypes.

There is a handful of other improvements besides that and I hope that all of 
them will be upstreamed over time.

Best,
Andrej

> On 5 Oct 2023, at 12:08, Houman  wrote:
> 
> Hi Andrej,
> 
> That's absolutely brilliant. Thank you for showing love to this
> project. I have pointed my SPM to your repo and it worked right away.
> What is the WireguardKitType?  That wasn't there before, but It seems
> to be working even without adding that to my project.
> 
> I've starred your project too. Well done.
> 
> Best,
> Houman
> 
> 
> 
> 
> 
> On Thu, 5 Oct 2023 at 10:28, Andrej Mihajlov  wrote:
>> 
>> Hi Houman,
>> 
>> I maintain a fork of wireguard-apple for the past couple of years and it 
>> works with Xcode 15 and Swift 5.9:
>> github.com/mullvad/wireguard-apple (branch: mullvad-master)
>> 
>> In the app I maintain, WireGuardGoBridge target is built using bash script 
>> for flexibility, instead of bash sorcery so you might want this too:
>> github.com/mullvad/mullvadvpn-app/blob/main/ios/build-wireguard-go.sh 
>> <http://github.com/mullvad/mullvadvpn-app/blob/main/ios/build-wireguard-go.sh>
>> 
>> Hope any of this helps.
>> 
>> Best,
>> Andrej
>> 
>>> On 4 Oct 2023, at 18:04, Houman  wrote:
>>> 
>>> Hello Andrej,
>>> 
>>> Thank you for your reply.  I have already forked the branch and set
>>> Package.swift to swift-tools-version:5.5. But I still get the same
>>> error as before.
>>> 
>>> Swift-tools-version:5.5 only worked with the previous version
>>> 1.0.15-26 that was released on 23rd Sep 2021.
>>> The 1.0.16-27 that was tagged on 15th Feb 2023 is completely broken
>>> and doesn't work with SPM.  I have tried swift-tools-versions 5.6,
>>> 5.7, 5.8 and 5.9.  I strongly believe that this commit from Jason
>>> ccc7472fd7d1c7c19584e6a30c45a56b8ba57790 on 14th Feb 2023 has broken
>>> it.  I don't think he tested it afterwards with SPM.
>>> 
>>> This (outdated) PR proves that more people are having problems with
>>> installing the latest version since the February release:
>>> https://github.com/WireGuard/wireguard-apple/pull/24
>>> 
>>> Error Message:
>>> Invalid manifest (compiled with: "/Applications/Xcode
>>> app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/us/bin/swift",
>>> "visoverlay", 
>>> "/ar/folders/9m/lwx244892997kpg7vb5vsshgn/T/TemporaryDirectory.
>>> BBHXP8/vfs.yaml*, "-", "/Applicationscode.
>>> app/Contents/SharedFrameworks/SwiftM.framework/SharedSupport/ManifestA*,
>>> "PackageDescription, "-Xlinker", "-rath", "-Xlinker", "/Applicatio..
>>> 
>>> Xcode version: Version 15.0 (15A240d)
>>> Mac version: 14.0 (23A344)
>>> 
>>> Your help is much appreciated,
>>> Thanks,
>>> Houman
>>> 
>>> 
>>> On Wed, 4 Oct 2023 at 12:46, Andrej Mihajlov  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Right. I think that preamble in Package.swift should be changed from:
>>>> 
>>>>> // swift-tools-version:5.3
>>>> 
>>>> to at least:
>>>> 
>>>>> // swift-tools-version:5.5
>>>> 
>>>> Which works with Xcode 15 based on my experience.
>>>> 
>>>> Jason could you please bump it?
>>>> 
>>>> Best,
>>>> 
>>>> Andrej
>>>> 
>>>>> On 30 Sep 2023, at 21:09, Houman  wrote:
>>>>> 
>>>>> Hello Jason, Andrej
>>>>> 
>>>>> Please try to add the latest Wireguard-Apple 1.0.16-27 via Swift
>>>>> Package Manager and you will see that fails. The issue could be
>>>>> related to swift-tools-version.
>>>>> 
>>>>> Please advise what to do?
>>>>> Thank you.
>>>>> Houman
>>>> 
>> 

Re: Wireguard-apple 1.0.16-27 can’t be added via SPM

[Andrej Mihajlov]

Hi Houman,

I maintain a fork of wireguard-apple for the past couple of years and it works 
with Xcode 15 and Swift 5.9:
github.com/mullvad/wireguard-apple (branch: mullvad-master)

In the app I maintain, WireGuardGoBridge target is built using bash script for 
flexibility, instead of bash sorcery so you might want this too: 
github.com/mullvad/mullvadvpn-app/blob/main/ios/build-wireguard-go.sh 
<http://github.com/mullvad/mullvadvpn-app/blob/main/ios/build-wireguard-go.sh>

Hope any of this helps.

Best,
Andrej

> On 4 Oct 2023, at 18:04, Houman  wrote:
> 
> Hello Andrej,
> 
> Thank you for your reply.  I have already forked the branch and set
> Package.swift to swift-tools-version:5.5. But I still get the same
> error as before.
> 
> Swift-tools-version:5.5 only worked with the previous version
> 1.0.15-26 that was released on 23rd Sep 2021.
> The 1.0.16-27 that was tagged on 15th Feb 2023 is completely broken
> and doesn't work with SPM.  I have tried swift-tools-versions 5.6,
> 5.7, 5.8 and 5.9.  I strongly believe that this commit from Jason
> ccc7472fd7d1c7c19584e6a30c45a56b8ba57790 on 14th Feb 2023 has broken
> it.  I don't think he tested it afterwards with SPM.
> 
> This (outdated) PR proves that more people are having problems with
> installing the latest version since the February release:
> https://github.com/WireGuard/wireguard-apple/pull/24
> 
> Error Message:
> Invalid manifest (compiled with: "/Applications/Xcode
> app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/us/bin/swift",
> "visoverlay", 
> "/ar/folders/9m/lwx244892997kpg7vb5vsshgn/T/TemporaryDirectory.
> BBHXP8/vfs.yaml*, "-", "/Applicationscode.
> app/Contents/SharedFrameworks/SwiftM.framework/SharedSupport/ManifestA*,
> "PackageDescription, "-Xlinker", "-rath", "-Xlinker", "/Applicatio..
> 
> Xcode version: Version 15.0 (15A240d)
> Mac version: 14.0 (23A344)
> 
> Your help is much appreciated,
> Thanks,
> Houman
> 
> 
> On Wed, 4 Oct 2023 at 12:46, Andrej Mihajlov  wrote:
>> 
>> Hi,
>> 
>> Right. I think that preamble in Package.swift should be changed from:
>> 
>>> // swift-tools-version:5.3
>> 
>> to at least:
>> 
>>> // swift-tools-version:5.5
>> 
>> Which works with Xcode 15 based on my experience.
>> 
>> Jason could you please bump it?
>> 
>> Best,
>> 
>> Andrej
>> 
>>> On 30 Sep 2023, at 21:09, Houman  wrote:
>>> 
>>> Hello Jason, Andrej
>>> 
>>> Please try to add the latest Wireguard-Apple 1.0.16-27 via Swift
>>> Package Manager and you will see that fails. The issue could be
>>> related to swift-tools-version.
>>> 
>>> Please advise what to do?
>>> Thank you.
>>> Houman
>> 

Re: Wireguard-apple 1.0.16-27 can’t be added via SPM

[Andrej Mihajlov]

Hi,

Right. I think that preamble in Package.swift should be changed from:

> // swift-tools-version:5.3

to at least:

> // swift-tools-version:5.5

Which works with Xcode 15 based on my experience.

Jason could you please bump it?

Best,

Andrej

> On 30 Sep 2023, at 21:09, Houman  wrote:
> 
> Hello Jason, Andrej
> 
> Please try to add the latest Wireguard-Apple 1.0.16-27 via Swift
> Package Manager and you will see that fails. The issue could be
> related to swift-tools-version.
> 
> Please advise what to do?
> Thank you.
> Houman

Re: Wireguard iOS crashes after upgrading to XCode 14

[Andrej Mihajlov]

Hi Houman,

I believe that the crash coming from withMemoryRebound is actually assertion 
(assert()). Very often assertions are stripped out from release builds, so I 
guess it could be the reason why it just worked in release builds.

Jason has already replied in regards of releasing an update.

Best regards,
Andrej

> On 22 Sep 2022, at 10:56, Houman  wrote:
> 
> Hi Andrej,
> 
> It works, well done!
> 
> A strange thing though, before your patch I was still able to connect
> to the VPN server, if I changed the schema to Release instead of
> Debug.  Now with your patch it also works under Debug schema, which is
> fantastic.
> What could be the technical reason that it still worked under Release?
> 
> And what will happen now, are you able to actually get this patch
> released on the official repo? The repo hasn't been updated for a
> year.  :-)
> 
> Thanks,
> Houman
> 
> 
> On Thu, 22 Sept 2022 at 09:31, Andrej Mihajlov  wrote:
>> 
>> Hi,
>> 
>> I think we have a bug. If I am right, basically in both IPv4 and IPv6 
>> extensions, withMemoryRebound takes capacity which is actually a number of 
>> instances of a given type (sockaddr_ variant) and not the byte size of a 
>> struct.
>> 
>> Could you please patch your WireGuardKit with the following commit and see 
>> if it helps?
>> 
>> https://git.zx2c4.com/wireguard-apple/commit/?h=am/fix-addrinfo-crash
>> 
>> Best regards,
>> Andrey Mikhaylov
>> 
>>> On 13 Sep 2022, at 14:41, Houman  wrote:
>>> 
>>> My existing Wireguard iOS implementation stopped working after
>>> upgrading to Xcode 14 today.
>>> When trying to connect to servers that support only IPv4, then it's
>>> fine. But if the server supports both IPv6 and IPv4 then the tunnel
>>> crashes:
>>> 
>>> This IPv6 extension in
>>> wireguard-apple/Sources/WireGuardKit/IPAddress+AddrInfo.swift crashes
>>> with a Fatal Error at addrInfo.ai_addr.withMemoryRebound()
>>> 
>>> The whole extension below:
>>> 
>>> extension IPv6Address {
>>>   init?(addrInfo: addrinfo) {
>>>   guard addrInfo.ai_family == AF_INET6 else { return nil }
>>> 
>>>   let addressData = addrInfo.ai_addr.withMemoryRebound(to:
>>> sockaddr_in6.self, capacity: MemoryLayout.size) { ptr ->
>>> Data in
>>>   return Data(bytes: &ptr.pointee.sin6_addr, count:
>>> MemoryLayout.size)
>>>   }
>>>   self.init(addressData)
>>>   }
>>> }
>>> 
>>> Has anyone else experienced this problem?
>>> 
>>> Thanks,
>> 

Re: Wireguard iOS crashes after upgrading to XCode 14

[Andrej Mihajlov]

Hi,

I think we have a bug. If I am right, basically in both IPv4 and IPv6 
extensions, withMemoryRebound takes capacity which is actually a number of 
instances of a given type (sockaddr_ variant) and not the byte size of a 
struct. 

Could you please patch your WireGuardKit with the following commit and see if 
it helps? 

https://git.zx2c4.com/wireguard-apple/commit/?h=am/fix-addrinfo-crash

Best regards,
Andrey Mikhaylov

> On 13 Sep 2022, at 14:41, Houman  wrote:
> 
> My existing Wireguard iOS implementation stopped working after
> upgrading to Xcode 14 today.
> When trying to connect to servers that support only IPv4, then it's
> fine. But if the server supports both IPv6 and IPv4 then the tunnel
> crashes:
> 
> This IPv6 extension in
> wireguard-apple/Sources/WireGuardKit/IPAddress+AddrInfo.swift crashes
> with a Fatal Error at addrInfo.ai_addr.withMemoryRebound()
> 
> The whole extension below:
> 
> extension IPv6Address {
>init?(addrInfo: addrinfo) {
>guard addrInfo.ai_family == AF_INET6 else { return nil }
> 
>let addressData = addrInfo.ai_addr.withMemoryRebound(to:
> sockaddr_in6.self, capacity: MemoryLayout.size) { ptr ->
> Data in
>return Data(bytes: &ptr.pointee.sin6_addr, count:
> MemoryLayout.size)
>}
>self.init(addressData)
>}
> }
> 
> Has anyone else experienced this problem?
> 
> Thanks,

Re: WireGuardKit iOS - Import package and usage of 'Shared' classes

[Andrej Mihajlov]

Hi,

The source code under Sources/Shared is a part of WireGuard app. These files 
are checked out by SPM, because both WireGuardKit and WireGuard app share the 
same repository. However, these files aren’t part of WireGuardKit and thus not 
available for direct import via WireGuardKit.

Best,
Andrej

> On 20 Mar 2022, at 16:24, Alexey Ponkin  wrote:
> 
> Hi guys,
> I'm trying to use WiregurdKit in my iOS app. I imported the package as
> described here - https://github.com/WireGuard/wireguard-apple. Now I
> can use `PacketTunnelProvider` inside `WireGuardNetworkExtension`. But
> unfortunately , I can't use any classes and extensions from the
> `Shared` folder
> (https://github.com/WireGuard/wireguard-apple/tree/master/Sources/Shared).
> Is there any way to make them 'visible' for my project? I'm fairly new
> to Swift and iOS development. I would like, for instance, to reuse
> this extension 
> (https://github.com/WireGuard/wireguard-apple/blob/master/Sources/Shared/Model/NETunnelProviderProtocol%2BExtension.swift)
> and may be, `Keychan` wrapper class.
> Thanks in advance for your help.

Re: [wireguard-apple] [iOS] Changing network fails with includeAllNetworks (Kill Switch)

[Andrej Mihajlov]

Follow up on this. It looks like the VPN connection breaks on my iPad running 
iPadOS 15 after changing DNS settings via WireGuardKit. 

Tested on iPadOS 15.1 beta today and it seems to be stable.

> On 28 Sep 2021, at 13:03, Andrej Mihajlov  wrote:
> 
> Hi,
> 
> I can confirm that it behaves correctly on iOS 15 (tested on iPhone 12) and 
> iOS 15.1 beta (tested on iPhone 7). Tested by toggling cellular/wi-fi and 
> airplane mode on both devices and network monitor seems to be functioning 
> properly. 
> 
> I haven’t tested this patch on iOS 14.8, but I had previously tested it on 
> iOS 14.5 (IIRC) and it didn’t work there, that's why this patch is scoped to 
> iOS 15+.
> 
> I am running the "am/enable-include-all-networks" branch which has the 
> following changeset:
> https://git.zx2c4.com/wireguard-apple/commit/?id=07bc66e7b181fb2068d457b31c1fdd05bdd2214a&id2=58e94f077329f6c7b96ec069243495d4e649fe36
> 
> Cheers,
> Andrej
> 
>> On 22 Sep 2021, at 15:26, Juraj Hilje  wrote:
>> 
>> Hi Andrej,
>> 
>> I've tested on iOS/iPadOS 15.1 Beta, and it looks like the issue is fixed 
>> there.
>> Let me know if you can confirm the same on your end.
>> 
>> Cheers,
>> Juraj H.
>> 
>>> On 22.09.2021., at 10:59, Andrej Mihajlov  wrote:
>>> 
>>> Hi Juraj,
>>> 
>>> Installing iOS 15 right now. I am gonna test it today too. 
>>> 
>>> What stands out to me that, while you have multiple interfaces available, 
>>> the network monitor still says that the network is unsatisfied. Very odd.
>>> 
>>> Cheers,
>>> Andrej
>>> 
>>>> On 22 Sep 2021, at 10:55, Juraj Hilje  wrote:
>>>> 
>>>> Hey Andrej, thanks for the response!
>>>> 
>>>> I've tested on iOS 14.8 and iOS 15.0 (public release), and even with the 
>>>> patch (b244febfdf3069dd4e8db2d31f0368d5474d7616) i still have the same 
>>>> issue on my end.
>>>> 
>>>> I will test the new iOS 15.1 Beta later today and let you know how it goes.
>>>> 
>>>> Juraj H.
>>>> 
>>>>> On 22.09.2021., at 10:08, Andrej Mihajlov  wrote:
>>>>> 
>>>>> Have you tried on the most recent beta? I think it works over there, but 
>>>>> requires some tweaks to the network monitor code in WireGuard. I had a 
>>>>> patch somewhere here but haven’t spent much time testing it:
>>>>> 
>>>>> https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616
>>>>> 
>>>>> Waiting for the final release of iOS 15.
>>>>> 
>>>>>> On 21 Sep 2021, at 12:55, Juraj Hilje  wrote:
>>>>>> 
>>>>>> If NETunnelProviderProtocol is configured with includeAllNetworks=true 
>>>>>> (Kill Switch), when network change is detected the device connectivity 
>>>>>> goes offline instead of routing VPN tunnel traffic through a new network.
>>>>>> 
>>>>>> Here are some logs from the moment of this event:
>>>>>> 2021-09-20 12:07:26.735453: [NET] Network change detected with 
>>>>>> unsatisfied route and interface order [en0, utun4, pdp_ip0]
>>>>>> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
>>>>>> 2021-09-20 12:07:26.736732: [NET] Device closing
>>>>>> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
>>>>>> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
>>>>>> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
>>>>>> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
>>>>>> 2021-09-20 12:07:26.746712: [NET] peer(eN1f…Oymc) - Stopping
>>>>>> 2021-09-20 12:07:26.751550: [NET] peer(eN1f…Oymc) - Routine: sequential 
>>>>>> receiver - stopped
>>>>>> 2021-09-20 12:07:26.751597: [NET] peer(eN1f…Oymc) - Routine: sequential 
>>>>>> sender - stopped
>>>>>> 2021-09-20 12:07:26.753433: [NET] Device closed
>>>>>> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
>>>>>> 
>>>>>> Tested on devices: iOS 14.8, iPadOS 15
>>>>>> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
>>>>>> 
>>>>>> More info on includeAllNetworks option:
>>>>>> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
>>>>>> 
>>>>>> Can someone confirm this issue or point to a possible workaround?
>>>>>> Thanks!
>>>>>> 
>>>>>> Juraj H.
>>>>> 
>>>> 
>>> 
>> 
> 

Re: [wireguard-apple] [iOS] Changing network fails with includeAllNetworks (Kill Switch)

[Andrej Mihajlov]

Hi,

I can confirm that it behaves correctly on iOS 15 (tested on iPhone 12) and iOS 
15.1 beta (tested on iPhone 7). Tested by toggling cellular/wi-fi and airplane 
mode on both devices and network monitor seems to be functioning properly. 

I haven’t tested this patch on iOS 14.8, but I had previously tested it on iOS 
14.5 (IIRC) and it didn’t work there, that's why this patch is scoped to iOS 
15+.

I am running the "am/enable-include-all-networks" branch which has the 
following changeset:
https://git.zx2c4.com/wireguard-apple/commit/?id=07bc66e7b181fb2068d457b31c1fdd05bdd2214a&id2=58e94f077329f6c7b96ec069243495d4e649fe36

Cheers,
Andrej

> On 22 Sep 2021, at 15:26, Juraj Hilje  wrote:
> 
> Hi Andrej,
> 
> I've tested on iOS/iPadOS 15.1 Beta, and it looks like the issue is fixed 
> there.
> Let me know if you can confirm the same on your end.
> 
> Cheers,
> Juraj H.
> 
>> On 22.09.2021., at 10:59, Andrej Mihajlov  wrote:
>> 
>> Hi Juraj,
>> 
>> Installing iOS 15 right now. I am gonna test it today too. 
>> 
>> What stands out to me that, while you have multiple interfaces available, 
>> the network monitor still says that the network is unsatisfied. Very odd.
>> 
>> Cheers,
>> Andrej
>> 
>>> On 22 Sep 2021, at 10:55, Juraj Hilje  wrote:
>>> 
>>> Hey Andrej, thanks for the response!
>>> 
>>> I've tested on iOS 14.8 and iOS 15.0 (public release), and even with the 
>>> patch (b244febfdf3069dd4e8db2d31f0368d5474d7616) i still have the same 
>>> issue on my end.
>>> 
>>> I will test the new iOS 15.1 Beta later today and let you know how it goes.
>>> 
>>> Juraj H.
>>> 
>>>> On 22.09.2021., at 10:08, Andrej Mihajlov  wrote:
>>>> 
>>>> Have you tried on the most recent beta? I think it works over there, but 
>>>> requires some tweaks to the network monitor code in WireGuard. I had a 
>>>> patch somewhere here but haven’t spent much time testing it:
>>>> 
>>>> https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616
>>>> 
>>>> Waiting for the final release of iOS 15.
>>>> 
>>>>> On 21 Sep 2021, at 12:55, Juraj Hilje  wrote:
>>>>> 
>>>>> If NETunnelProviderProtocol is configured with includeAllNetworks=true 
>>>>> (Kill Switch), when network change is detected the device connectivity 
>>>>> goes offline instead of routing VPN tunnel traffic through a new network.
>>>>> 
>>>>> Here are some logs from the moment of this event:
>>>>> 2021-09-20 12:07:26.735453: [NET] Network change detected with 
>>>>> unsatisfied route and interface order [en0, utun4, pdp_ip0]
>>>>> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
>>>>> 2021-09-20 12:07:26.736732: [NET] Device closing
>>>>> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
>>>>> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
>>>>> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
>>>>> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
>>>>> 2021-09-20 12:07:26.746712: [NET] peer(eN1f…Oymc) - Stopping
>>>>> 2021-09-20 12:07:26.751550: [NET] peer(eN1f…Oymc) - Routine: sequential 
>>>>> receiver - stopped
>>>>> 2021-09-20 12:07:26.751597: [NET] peer(eN1f…Oymc) - Routine: sequential 
>>>>> sender - stopped
>>>>> 2021-09-20 12:07:26.753433: [NET] Device closed
>>>>> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
>>>>> 
>>>>> Tested on devices: iOS 14.8, iPadOS 15
>>>>> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
>>>>> 
>>>>> More info on includeAllNetworks option:
>>>>> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
>>>>> 
>>>>> Can someone confirm this issue or point to a possible workaround?
>>>>> Thanks!
>>>>> 
>>>>> Juraj H.
>>>> 
>>> 
>> 
> 

Re: [wireguard-apple] [iOS] Changing network fails with includeAllNetworks (Kill Switch)

[Andrej Mihajlov]

Hi Juraj,

Installing iOS 15 right now. I am gonna test it today too. 

What stands out to me that, while you have multiple interfaces available, the 
network monitor still says that the network is unsatisfied. Very odd.

Cheers,
Andrej

> On 22 Sep 2021, at 10:55, Juraj Hilje  wrote:
> 
> Hey Andrej, thanks for the response!
> 
> I've tested on iOS 14.8 and iOS 15.0 (public release), and even with the 
> patch (b244febfdf3069dd4e8db2d31f0368d5474d7616) i still have the same issue 
> on my end.
> 
> I will test the new iOS 15.1 Beta later today and let you know how it goes.
> 
> Juraj H.
> 
>> On 22.09.2021., at 10:08, Andrej Mihajlov  wrote:
>> 
>> Have you tried on the most recent beta? I think it works over there, but 
>> requires some tweaks to the network monitor code in WireGuard. I had a patch 
>> somewhere here but haven’t spent much time testing it:
>> 
>> https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616
>> 
>> Waiting for the final release of iOS 15.
>> 
>>> On 21 Sep 2021, at 12:55, Juraj Hilje  wrote:
>>> 
>>> If NETunnelProviderProtocol is configured with includeAllNetworks=true 
>>> (Kill Switch), when network change is detected the device connectivity goes 
>>> offline instead of routing VPN tunnel traffic through a new network.
>>> 
>>> Here are some logs from the moment of this event:
>>> 2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied 
>>> route and interface order [en0, utun4, pdp_ip0]
>>> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
>>> 2021-09-20 12:07:26.736732: [NET] Device closing
>>> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
>>> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
>>> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
>>> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
>>> 2021-09-20 12:07:26.746712: [NET] peer(eN1f…Oymc) - Stopping
>>> 2021-09-20 12:07:26.751550: [NET] peer(eN1f…Oymc) - Routine: sequential 
>>> receiver - stopped
>>> 2021-09-20 12:07:26.751597: [NET] peer(eN1f…Oymc) - Routine: sequential 
>>> sender - stopped
>>> 2021-09-20 12:07:26.753433: [NET] Device closed
>>> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
>>> 
>>> Tested on devices: iOS 14.8, iPadOS 15
>>> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
>>> 
>>> More info on includeAllNetworks option:
>>> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
>>> 
>>> Can someone confirm this issue or point to a possible workaround?
>>> Thanks!
>>> 
>>> Juraj H.
>> 
> 

Re: [wireguard-apple] [iOS] Changing network fails with includeAllNetworks (Kill Switch)

[Andrej Mihajlov]

Have you tried on the most recent beta? I think it works over there, but 
requires some tweaks to the network monitor code in WireGuard. I had a patch 
somewhere here but haven’t spent much time testing it:

https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616

Waiting for the final release of iOS 15.

> On 21 Sep 2021, at 12:55, Juraj Hilje  wrote:
> 
> If NETunnelProviderProtocol is configured with includeAllNetworks=true (Kill 
> Switch), when network change is detected the device connectivity goes offline 
> instead of routing VPN tunnel traffic through a new network.
> 
> Here are some logs from the moment of this event:
> 2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied 
> route and interface order [en0, utun4, pdp_ip0]
> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
> 2021-09-20 12:07:26.736732: [NET] Device closing
> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
> 2021-09-20 12:07:26.746712: [NET] peer(eN1f…Oymc) - Stopping
> 2021-09-20 12:07:26.751550: [NET] peer(eN1f…Oymc) - Routine: sequential 
> receiver - stopped
> 2021-09-20 12:07:26.751597: [NET] peer(eN1f…Oymc) - Routine: sequential 
> sender - stopped
> 2021-09-20 12:07:26.753433: [NET] Device closed
> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
> 
> Tested on devices: iOS 14.8, iPadOS 15
> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
> 
> More info on includeAllNetworks option:
> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
> 
> Can someone confirm this issue or point to a possible workaround?
> Thanks!
> 
> Juraj H.

Re: WireGuard is broken on iOS 15 beta

[Andrej Mihajlov]

It was less about performance but more about security. Just wanted to share 
some good news!

A little bit of background story:

There was an article a little while ago that highlighted a traffic leak, when 
connections established before the VPN would continue going through the primary 
interface outside of the tunnel: 
https://protonvpn.com/blog/apple-ios-vulnerability-disclosure/

Then at some point around iOS 14.2, Apple introduced a kill-switch to address 
that issue (via VPN configuration flag). 

However it never really worked with WireGuard as the tunnel would always fail 
to establish the connection with peers. There is a thread on Apple forums with 
some of Apple engineers trying to figure out what’s going on:
https://developer.apple.com/forums/thread/653116


Now it’s too early to say, but I just ran WireGuard with kill switch enabled on 
iOS 15 beta and the tunnel is magically up and running, which was still broken 
on iOS 14.3. I am going to test it on iOS 14.4 today too. So it looks like 
Apple did something to fix their SDK to make the kill switch work.

Potential low effort improvement for WG, in practice it looks as such:

let protocolConfig = NETunnelProviderProtocol()
if #available(iOS 15.0, *) {
protocolConfig.includeAllNetworks = true // kill-switch
protocolConfig.excludeLocalNetworks = true // enable LAN networking
}

Cheers,
Andrej

> On 10 Jun 2021, at 13:51, Jason A. Donenfeld  wrote:
> 
> Patches with a proper performance comparison of the two techniques in
> the description would be appreciated.
> 
> Thanks,
> Jason

Re: WireGuard is broken on iOS 15 beta

[Andrej Mihajlov]

My approach worked too. However it relies on the private interfaces of 
NetworkExtension framework, which we’d probably want to avoid.

In short it can be expressed in one line as:

let fd = packetFlow.perform(Selector("interface")).toOpaque().advanced(by: 
0x128).assumingMemoryBound(to: Int32.self).pointee

But I bet that walking over fds is much safer.

Cheers,
Andrej

> On 11 Jun 2021, at 10:50, Jason A. Donenfeld  wrote:
> 
> Can I infer from that that your technique didn't work? Some
> confirmation one way or another there would be useful, so I know
> whether to dedicate some RE time next week to it or not. If I can
> avoid the fd iteration, I'd prefer that.
> 
> Jason

Re: WireGuard is broken on iOS 15 beta

[Andrej Mihajlov]

Jason,

My bad, you’re right regarding the Personal VPN.

I just ran your patch and it works great. As David pointed out, the call to 
valueForKeyPath should be guarded because it throws exception if the given key 
path does not exist. I use the availability check to bruteforce utun on iOS 15, 
macOS 12 and onwards while keeping the Key value coding approach on older iOS 
and macOS as we know that it works great on iOS < 15 and macOS < 12. Just ran 
the app on macOS 11.4 and it’s still working and using the old code path.

I took a liberty to refactor the proposed solution (see: 
https://git.zx2c4.com/wireguard-apple/commit/?id=a7ccc8e3031f3502ea4b53a914d37589186e40f8)

Cheers,
Andrej

> On 11 Jun 2021, at 09:53, Jason A. Donenfeld  wrote:
> 
> On 6/11/21, Andrej Mihajlov  wrote:
>> IIRC one thing to consider with that lookup: iOS enables users to run
>> Personal VPN and Custom VPN (aka WireGuard) side-by-side so there is a
>> chance you may pick the wrong utun.
> 
> That doesn't make any sense. File descriptors are not OS-global;
> they're process-local. That's how Unix FDs have worked since forever.
> Unless you're suggesting "personal VPN" is somehow resident in the
> same network extension process as WireGuard's "custom VPN"?
> 
> By the way, did the experiment in your branch work? I'd prefer a
> direct route to brute forcing FDs, if possible. But if not, seems like
> my kludge might ultimately do the trick.

Re: WireGuard is broken on iOS 15 beta

[Andrej Mihajlov]

IIRC one thing to consider with that lookup: iOS enables users to run Personal 
VPN and Custom VPN (aka WireGuard) side-by-side so there is a chance you may 
pick the wrong utun.

> On 11 Jun 2021, at 00:33, David Crawshaw  wrote:
> 
> I finally managed to get a device running iPadOS 15 and an Xcode 13
> beta. This technique works. Some modified code with logging:
> 
> func tunnelFD(provider: NEPacketTunnelProvider) -> Int32 {
>os_log("tunnelFD searching")
>var buf = [CChar](repeating: 0, count: Int(IFNAMSIZ))
>for fd: Int32 in 4...64 {
>var len = socklen_t(buf.count)
>if getsockopt(fd, 2 /* SYSPROTO_CONTROL */, 2, &buf, &len) == 0 {
>let str = String(cString: buf)
>os_log("%{public}@", "tunnelFD \(fd): \(str)")
>if str.starts(with: "utun") {
>os_log("tunnelFD found likely fd")
>return fd
>}
>}
>}
>os_log("tunnelFD found nothing")
>return -1
> }
> 
> produces the logs:
> 
>tunnelFD searching
>tunnelFD 7: utun3
>tunnelFD found likely fd
> 
> Note that the current technique of calling
> provider.packetFlow.value(forKeyPath: "socket.fileDescriptor") causes
> the NetworkExtension to crash under iOS 15. The logs say the kernel
> sandbox killed it:
> 
>Sandbox: process(525) deny(2) file-test-existence /private/etc/.mdns_debug
> 
> On Thu, Jun 10, 2021 at 8:44 AM Jason A. Donenfeld  wrote:
>> 
>> I won't have an updated OS to test this out in until next week at the
>> earliest, but perhaps this hack will work?
>> https://git.zx2c4.com/wireguard-apple/commit/?h=jd/fd-search-hack
>> Let me know if that is successful, or if it blows up.
>> 
>> Jason

WireGuard is broken on iOS 15 beta

[Andrej Mihajlov]

Hi,

Just though to give you heads up. iOS 15 beta is out and it looks like the old 
way of obtaining the tunnel device descriptor is no longer working as the 
internal structure of NEPacketFlow has changed. It’s been a ticking bomb form 
the start as with any private API that is subject to change without a warning. 

In the short term, researching what Apple changed and looking for a quick fix 
for that. Longer term I believe we should have a better integration between 
wireguard-go and Network extension on iOS.

Cheers,
Andrej Mihajlov

Fwd: git-доступ к исходникам wiregard

[Andrej Mihajlov]

> Begin forwarded message:
> 
> From: langry 
> Subject: git-доступ к исходникам wiregard
> Date: 29 January 2021 at 09:06:40 CET
> To: a...@mullvad.net
> 
> Добрый день, Андрей.
> 
> Не могу пробиться к исходникам по вашей инструкции: 
> https://git.zx2c4.com/wireguard-apple/about/
> 
> "fatal: unable to access 'https://git.zx2c4.com/wireguard-apple/': 
> error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake 
> failure"
> 
> Пытаюсь собрать под старые маки версий 10.6–10.9… или зря трачу время?
> 
> -- 
> Евгений

Re: Wireguard on MacOS (Catalina) not able to quit/deactivate

[Andrej Mihajlov]

Hi,

I see the same issue. Possible side effect of having `exit(0)` in `stopTunnel`?

https://github.com/WireGuard/wireguard-apple/blob/master/WireGuard/WireGuardNetworkExtension/PacketTunnelProvider.swift#L102
 


Cheers,
Andrej

> On 16 Jan 2020, at 15:18, Revath S Kumar  wrote:
> 
> Found the issue. 
> This is due to On demand option is ON. 
> 
> Once On demand is OFF you can deactivate and quit.
> 
> 
> On Wed, Nov 27, 2019 at 7:45 AM Revath S Kumar  > wrote:
> Hello all,
> 
> I installed wireguard on MacOS (Catalina) recently.
> After I configured and activated once, I am not able to quit/deactivate the 
> wireguard session.
> I am attaching Gifs for your reference. [1]
> 
>  Even I tried to kill the process via Activity Monitor but a process names 
> WireguardNetworkExtension, shows up again. [2]
> 
> [1]: https://imgur.com/CEm4cXM 
> [2]: https://imgur.com/xC8uCUy 
> 
> with regards,
> Revath S Kumar,
> JavaScripter / Rubyist 
> https://blog.revathskumar.com/ 
> ___
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard