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

Kaycekaycee

Nobody ever could figure out what the other guy was up to. Similarly, I have absolutely no idea what you're doing either. What are you trying to do? – Jenn

I've updated my answer with the specific use case I'm going after and an example – Kaycekaycee

why for the sake of god is this question migrated here instead of the superuser? – Brittabrittain

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. :)

Fernand

Ah, that makes sense. I didn't realize tun had tap built in (monkey.org/openbsd/archive/tech/0406/msg00111.html) on bsd. On linux I believe the same thing has happened. – Kaycekaycee

Going by the man pages from FreeBSD 9.1 and NetBSD 6, that patch applies only to OpenBSD. OpenBSD is the odd one out that doesn't separate tap from tun in /dev. – Fernand

Does not answer original question: "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." And yet that's exactly what this answer does: gives a point to point IP address for a tun device so it has a destination. – Subedit

The answer is in the first paragraph: "Open a tap device instead." The rest of the answer is background detail for the question. – Fernand

"By default, tun devices operate in the layer 3 mode, aka point to point." > I don't agree that "layer 3" means "point to point". To me, a "layer 3" virtual interface means that the interface operates at the IP level (i.e. it takes and receives IP packets with an IP header, as opposed to, say, an Ethernet header). I don't see why a virtual interface that deals with IP packets has to be "point to point" - in fact, the two concepts seem pretty much unrelated. This seems to be a limitation of Mac OS (which Linux doesn't have). – Mitosis

Answer 2

Wireguard adds multiple address to the utun devices it creates. If you create a wireguard wg-quick conf file with multiple comma separated addresses in its "Address" key in the "Interface" section, it will bring up a utun interface with multiple addresses.

And then if you run wg-quick up with that conf file, it helpfully prints the commands it runs to achieve that effect.

Example:

[Interface]
PrivateKey=REDACTED
Address=fdc3:cbe8:ded7:491e::/64,172.21.0.207/24,192.168.78.7/24

Output:

[#] ifconfig utun3 inet6 fdc3:cbe8:ded7:491e::/64 alias
[#] ifconfig utun3 inet 172.21.0.207/24 172.21.0.207 alias
[#] ifconfig utun3 inet 192.168.78.7/24 192.168.78.7 alias
[#] ifconfig utun3 up

Those ifconfig commands work great for me for non-wireguard utun devices.

Your question specifies "without providing a destination address". So this solution perhaps doesn't technically answer your question. But since this solution sets the destination address to the same as the source address, it's not really a true destination address. It certainly allows me to communicate with addresses other than the destination.

Vast