The example tries to create an infinite numbers of TCP connections.

[atereshkin]

If you run the example and execute curl 1.1.1.1 --interface utun8 as suggested in the comment in forward.rs, it goes into an infinite loop opening connections to 1.1.1.1:80.

I might be missing something, but the problem seems to be that new_tcp_stream binds outgoing connections to the same tun interface used to receive packets from the OS, resulting in an infinite "recursion". Commenting out this line seems to work as a fix.

[cavivie]

From your argument, you seem to be using a Linux environment, right?

First, to make the example run successfully, you need to determine what the routing rules of your system are.
If you specify an interface in curl, curl will create a socket and bind to the interface, and then send the socket data through the interface. Then, since the forward example will create a utun device and listen to it, it should be able to receive the data packets sent from curl. By default, forward should send the data packets directly to the target service specified by curl, which is fine.

There is a problem. If the system sets the utun interface as the default route, if forward does nothing, the data packet will be sent from the utun device, which will cause a routing loop. In order to solve this problem, it is necessary to let forward bind to the network card device that can actually send data before sending it out, which will not cause the data packet to enter the forward again to form a loop, or use data packet mark and other technologies. Here, it is just a simple binding interface to simplify the example.

The final problem is whether the device bound to forward is the utun device created by forward itself. Since forward uses a guessing method for simplicity, you need to test whether the interface option is the same as utun to ensure that the guessed device is correct. The device needs to be a network interface card that can actually send data. If the guess is wrong, you need to provide the interface data sending device option yourself, or adjust the guessing logic.

[atereshkin]

@cavivie Yes, I'm on Linux. I haven't created any routes nor changed my default route (I did try the option with routes to the same effect, but let's ignore it for now). From your comment it sounds like the --interface option is for the interface to use for actual network connections. But since 3a7e0b9 it's also used to determine the tun device name, which seems to be the reason for the infinite loop: cfg.tun_name(&opt.interface) (line 95)

[cavivie]

OK, thanks for your careful observation!
I found that this was caused by insufficient carefulness in a PR review.
Would you mind providing a PR for this?