How do I set an ip address for TUN interface on OSX (without destination address)?

Question

How do I set an IP address for a TUN interface on OSX? I cannot figure out how to set up an ip address for my interface without specifying a destination IP. I don't want to do that- I'm want to more or less build a tunnel to an arbitrary address at a later point in time. Prior questions which are unhelpful:

1. There's a question that has an unclear answer, so I tried following the reference.
2. This question sets a point to point ip address for a tun device, so it has a destination, which is exactly what I don't want.

On the page for osxtuntap it says:

ifconfig tap0 10.1.2.3 up

I cannot make this work on OSX 10.6 for a TUN interface:

$ sudo ifconfig tun0 10.1.2.3 up
ifconfig: ioctl (SIOCAIFADDR): Destination address required

Adding a netmask doesn't help- OSX seems to demand a destination address:

$ ifconfig tun0 10.0.0.1/24 netmask 255.255.255.0
ifconfig: ioctl (SIOCAIFADDR): Destination address required

For linux, I get how it works. According to this page, you open() the interface, and use the ip command, and do this, and I've done this before with zero issues:

$ ip link set tun0 up
$ ip addr add 10.0.0.1/24 dev tun0

All I want to do is the same thing that I can do in linux.

---

EDIT:

I'm writing a little UDP tunnel app. Like so:

tun1 -> udp app #1 -> udp tunnel -> udp app #2 -> tun2

If the udp apps are on different computers (let's say local and remote), I'd like to associate their respective tun devices with an ip address, so I can send a packet from local to remote via the tunnel by sending the packet to the ip address of the tun device on the remove machine.

To borrow more from the linux tutorial, the author sets up a tun device on local and remote, associates ips, and runs a simple tunneling app, and then pings the other end of the tunnel:

[remote]# ip link set tun3 up
[remote]# ip addr add 192.168.0.2/24 dev tun3
[remote]$ ./simpletun -i tun3 -s
# server blocks waiting for the client to connect
[local]# ip link set tun11 up
[local]# ip addr add 192.168.0.1/24 dev tun11
[local]$ ./simpletun -i tun11 -c 10.2.3.4
# nothing happens, but the peers are now connected
[local]$ ping 192.168.0.2

Answer 1

By default, tun devices operate in the layer 3 mode, aka point to point. You're asking for layer 2 mode which more closely resembles a generic Ethernet device. Linux calls these tap devices. In OpenBSD you can switch a tun device into layer 2 mode with "ifconfig tun0 link0". The Macintosh tuntaposx driver mimics Linux' device schism; open a tap device instead.

You might want to review https://community.openvpn.net/openvpn/wiki/BridgingAndRouting to determine if you really want tap devices. They add a little overhead. If you just need two boxes to pass IP packets between each other and no bridging or broadcasting to a larger subnet, point to point should be sufficient.

For example, if you have two machines, one we label "local" with a LAN IP address like 192.168.0.12 and another we label "remote" with a LAN IP address like 192.168.1.14, you can assign tunnel IP addresses thusly:

ifconfig tun0 inet 10.0.0.1 10.0.0.2 up

on the local system, and:

ifconfig tun0 inet 10.0.0.2 10.0.0.1 up

on the remote system. Note the reversed perspective on the remote machine. Do not set your point to point addresses to anything on an existing subnet; it will not route properly.

I can't stress this enough: read and re-read the manual pages ("man ifconfig" and "man tun", probably others) until they make sense. My ifconfig examples above may differ slightly from your operating system.

And for another perspective you might look into GRE tunnels as their functionality mirrors what you describe for your program. However, GRE is likely not viable in today's TCP-centric networks nor is it a good idea due to major security issues.

If your goal is to circumvent an overbearing firewall, be aware that many such firewalls block UDP (and especially GRE) packets. In such a case, try SSH interface tunneling to set up tun/tap interfaces and forward packets. You get encryption and optionally compression as well. :)