When creating a TUN device in Linux, on my machine the created TUN device has following flags:


Clearly MULTICAST is listed in there but not BROADCAST. Since TUN device works with IP packets, it's the program that handles the TUN device file that should decide what to do with packets sent to broadcasting address. Moreover, it's also legal for applications to send packets to broadcasting address on TUN device even if BROADCAST flag is not listed on this device.

So why doesn't TUN device have BROADCAST flag?

EDIT: Sorry for the confusion. By TUN device, I don't mean specifically the way OpenVPN uses for tunneling. I mean TUN device in Linux (or other Unix) like described here: http://www.kernel.org/doc/Documentation/networking/tuntap.txt


The key to this is the fact that it's "POINTTOPOINT" ... Your machine directly connects to the remote side, and any actual broadcasts must be generated by your remote end. Sure, if you send a packet to the broadcast address, your remote end will surely pass it on, and will also pass any packets sent to the broadcast address back to you.

In contrast, if you had multiple workstations plugged directly into a switch, your machine could send a broadcast, and it wouldn't require any gateway to re-transmit that broadcast to the other peers.

  • But it doesn't have to be POINTTOPOINT either. The TUN device is handled by another program running on the machine where the TUN device is created. It's this program that decides how to deal with packets. If there's no remote server, but other equivalent machines with TUN devices, this program can certainly broadcast this packet to those clients. Upon receiving broadcasted packets, the same program on other machines can then write them into TUN device. – Song Gao Oct 31 '12 at 16:02
  • A tunnel interface is always a point-to-point interface. There is always only a single "remote end". What the remote end actually IS (VPN server in another network, or an application running on the local machine, etc... ) is irrelevant. How it behaves is the same. Everything is UNICAST to the remote end, and the remote end determines what to do with it. – TheCompWiz Oct 31 '12 at 16:41
  • 1
    TUN device doesn't connect to a "remote end" itself. It's just a virtual device existing in kernel but not mapped to a physical device. It might be a little misleading to post this question here because most people would think of TUN as the way VPN uses as tunneling. Yes VPN can use TUN device as tunneling, but it's not the only way to use it.Check out this: kernel.org/doc/Documentation/networking/tuntap.txt and examples here: backreference.org/2010/03/26/tuntap-interface-tutorial – Song Gao Oct 31 '12 at 18:30
  • @SongGao It's still a point-to-point interface. Just because each "point" can be an actual physical server somewhere else or an application behaving as a server of some sort... the results are the same. It is NOT a point-to-multipoint interface, and as such, you cannot have multiple "points" (applications or servers) involved without something behaving as a proxy. Every bit of communication is unicast. – TheCompWiz Nov 1 '12 at 15:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.