I ran into this at work with virtual box. Upgrade to Monterey helpfully tells you that a lot of your apps aren't going to work, after you have upgraded. Then anything using those system extensions fails every few days without explanation so you have to reinstall everything and push the car up the hill again.

> Upgrade to Monterey helpfully tells you that a lot of your apps aren't going to work, after you have upgraded.

I stopped using the word "upgrade" in reference to Apple's updates a long time ago.

From user point of view, removing support for kernel extensions is definitely a win, since it means more stable (and secure) system.

IME kernel extensions (kexts) were definitely related to various kernel panics that I've seen in the past.

In most cases, alternative APIs have been present for quite some time, it's just that some software hasn't been upgraded yet. Deprecation started a few years ago, so it's nothing surprising really.

Similar VPN and virtualization apps work without kexts, so I assume both Tunnelblick and VirtualBox could be rewritten to take the leverage of the new APIs.

VirtualBox is x86-64 only, I doubt they will invest time in updating anything for macos considering apple's decision to move everything and everyone to arm

>From user point of view, removing support for kernel extensions is definitely a win, since it means more stable (and secure) system.

At that point just use an iPhone/iPad. The whole point of OSX is that you have enough control over the machine that you can be productive.

Someone correct my foggy experience with this -

The 'tun' (tunnel) interface is user accessible, because it's creating a layer 3 packet/datagram, and programs are expected to need to be able to write these to do their job (web browsers send packets to a web server; email clients send packets to a mail server, et cetera)

The 'tap' (like a viper's fang injecting venom) interface is not user accessible. It requires a privilege escalation to perform the operation of receiving all of the layer 2 frames on a network interface. This allows the software access to greater information, and allows the reception and introduction of broadcast traffic, snooping on frames destined for other stations, and allows for a more comprehensive managing of the local network.

It's been a very long time.

`tun` lets a user-space process send/receive Layer 3 IP packets.

`tap` lets a user-space process send/receive Layer 2 Ethernet frames.

Ethernet is a layer below IP, so it doesn't care about IP addresses, in the same manner that Ethernet switches don't (it cares about MAC addresses instead).

If you want to do virtual switching, you'll use taps.

If you need to deal with a protocol that needs to use Ethernet broadcasts, like DHCP, you'll also use taps.

tap can be user accessible, it just needs to be part of a bridge (at least on Linux). The entire bridge consisting of one or more NICs will have an IP, and the individual interfaces of the bridge function like a switch.

Could a VM be used as a workaround? Assumably VMs are still going to support Ethernet. Maybe someone could write a super-lightweight VM (maybe using a unikernel) which just gets forwards Ethernet packets to/from a virtual socket?

Doesn't bridged networking on macOS require some kind of system "entitlement"? So in theory a "userspace" vm would suffer from host-only networking which replaces one problem with another.

I think we are getting close to swapping the machine roles here to have to most utility. Linux on metal and macOS in kvm for when you want to use an appstore app.

It requires “com.apple.vm.networking” entitlement, but only if you are a non-root user, the entitlement is not required if your process runs as root.

> Apple proposes that programs such as Tunnelblick be modified to use a different method to accomplish the function that the system extensions currently perform. The current Tunnelblick developers do not have the time or expertise to use the new method Apple proposes and have no plans to do so. Tunnelblick's value proposition is that it's a way to use OpenVPN on MacOS. What's its point if if stops doing that?

I'd have much more sympathy if it was a cross-platform application or if they had to keep rewriting/refactoring code multiple times because Apple kept changing different APIs from under their feet. That's not the case. Their only platform is macOS and AFAIK this is the only meaningful API migration they are being forced to do in 11 years. I know we cannot demand anything from Open Source maintainers, but is it really too much to ask that if you're the maintainer of a very popular security related application, you either learn how to code for the platform you're targeting or you pass on the torch?

I just don't understand the obsession with clinging on to being the unwilling maintainer for something that you don't master when the option of passing on the torch is always there. Someone willing will always pick up something as important as an OpenVPN client for an extremely popular operating system.

I recently started working on implementing a user space IP/TCP implementation on my MacBook and honestly configuring the utun driver is a huge pain, there isn’t really any good documentation for it and I ended up having to reverse engineer how to use it by looking at the source code of other projects that configured it (shout out to CloudFlares wire guard implementation!)

On top of that utun devices seem to add weird 4 bytes of data to the front of layer 3 packets to indicate the protocol (which was also confusing and undocumented AFAICT)

Tuns are easily fixed by using utuns. Tap is mostly an issue, but also a not-so-much an issue. There's a ok workaround of using `feth` interfaces with a `bpf` socket.

I think this is (2020)

I usually use OpenVPN Connect.