Replacing interface tap by feth couple of interfaces on macOS

[kabassanov]

Hi,

I'm actually trying to change openvpn code in order to keep tap behavior without using actual tap interfaces on macOS clients. This relies on a couple of native feth interfaces. Different approaches are possible:

• Using bpf interface for reading local packets and sending tunnel traffic to the interface through a socket
• Using bpf interface for reading local packets and sending tunnel traffic through the same bpf interface
• Creating a RW socket for the interface management in both directions.

For the moment, I'm working on the first one. This is what people suggest everytime somebody is talking about mac tap interfaces... The main issue is that bpf interface can put multiple packets into buffer during the same read action. I'm still looking for a simple solution to solve this. It is easy to get the first packet, the point is how to preserve remaining data until the next iteration of the tunnel_point_to_point loop. Probably with a secondary buffer and an additional TUN_READ_REMAIN status flag...

On the other hand, I wonder why the second approach is not suggested (all BPF)... What could be the issue with packet injections through the bpf?

Finally, the third approach seems to be more complex to implement, as actual socket management is related to c2 context and it will be necessary to get some socket functions widely visible.

What do you think?

Thanks.

[schwabe]

Using a temporary buffer and have some logic to see if there something in there when OpenVPN requests a read as hacky solution is probably the easiest way forward. When you have something works that way, we can probably built on that to make a cleaner implementation. Currently the pressure to do so, is not really big but having support for an feth driver would definitively push us main devs to spend time there to develop a non-hacky solution.

On the other hand, I wonder why the second approach is not suggested (all BPF)... What could be the issue with packet injections through the bpf?
To be honest, I am not that familiar with feth and BPF have an idea about that.

Not sure about the management interface option you propose, do you intent to pass data to the device back and forth via the management interface/socket?

[kabassanov]

Using a temporary buffer and have some logic to see if there something in there when OpenVPN requests a read as hacky solution is probably the easiest way forward. When you have something works that way, we can probably built on that to make a cleaner implementation. Currently the pressure to do so, is not really big but having support for an feth driver would definitively push us
main devs to spend time there to develop a non-hacky solution.

I have a code with basic features working (data traffic)... For the moment, it does not create feth interfaces by itself, but expects they were configured previously. I think it is not very hard to add creation. I've just migrated it to the master branch. Will try to create a PR with it.

On the other hand, I wonder why the second approach is not suggested (all BPF)... What could be the issue with packet injections through the bpf?
To be honest, I am not that familiar with feth and BPF have an idea about that.

Not sure about the management interface option you propose, do you intent to pass data to the device back and forth via the management interface/socket?

Sorry, I meant "Use a bidirectional socket instead of bpf"... But if the first approach can make it, I won't spend any time with this :)

[kabassanov]

#998