New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple unused utun interfaces after macOS upgrade #340

Open
essandess opened this Issue Nov 3, 2016 · 15 comments

Comments

Projects
None yet
3 participants
@essandess
Copy link

essandess commented Nov 3, 2016

My Mac has several unused utun0, utun1, interfaces after upgrading to Sierra.

This causes a problem with pf firewalls because Tunnelblick randomly assigns its interface to one of these, and if it's not the default utun0 listed in /etc/pf.conf, the tunnel doesn't work.

Does anyone know how to destroy these unused interfaces so that Tunnelblick reliably grabs utun0 on launch?

Trying to destroy existing utun interfaces with ifconfig throws this error:

sudo ifconfig utun0 destroy
ifconfig: SIOCIFDESTROY: Invalid argument

See, e.g., this pf.conf that depends on knowing which utun interface Tunnelblick uses.

@jkbullard

This comment has been minimized.

Copy link
Contributor

jkbullard commented Nov 3, 2016

OpenVPN uses "/sbin/ifconfig utun0 delete" to delete utun0 ("delete", not "destroy"), so you might try that (with sudo).

Or maybe changing the "dev tun" option in the configuration to "dev utun0" would force OpenVPN to use utun0.

That could cause other problems, I suppose, because It is a little-used and little-tested option, so Tunnelblick may not deal with it properly. For example, you might need to tell Tunnelblick to never load its tun driver if Tunnelblick doesn't deal with the option properly. You can do that in the "Advanced" settings window. But that's just a guess, it may work fine.

(If you have "pf" expertise, have you considered helping Tunnelblick use "pf"? Please take a look at this "help wanted" post.)

@essandess

This comment has been minimized.

Copy link
Author

essandess commented Nov 3, 2016

The ifconfig delete command reigns the following error, which appears in lots of Tunnelblick logs:

sudo ifconfig utun0 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address

I was able to remove most of the superfluous utun devices by deleting their appearance in the routing table, then rebooting. I believe, but am not certain, that these unnecessary utun devices are related to repeated upgrades of Tunnelblick. The commands look like a bunch of this:

netstat -rn | grep utun
sudo route delete -inet6 -ifscope utun0 -net ff01::%utun0/32
sudo route delete -inet6 -ifscope utun2 default fe80::%utun2
sudo route delete -inet6 -ifscope utun3 -net fe80::%utun3
...

After these steps:

  1. Delete utun appearance from routing table
  2. Delete Tunnelblick
  3. Reboot
  4. Reinstall Tunnelblick

I still have a utun0 interface on boot.

For now, I've simply replaced utun0 in /etc/pf.conf with utun1 and hope that these interfaces don't swap names on boot.

_Update:_ All my unnecessary utun interfaces have reappeared since I posted a few minutes ago. No idea how they're being created, how to get rid of them, or how to ensure Tunnelblick always grabs the same utun interface on boot.

@essandess

This comment has been minimized.

Copy link
Author

essandess commented Nov 3, 2016

Re: your pf help wanted post

For now, I can point to a fully functional pf.conf firewall configuration for a Tunnelblick-based OpenVPN Server at the repo osx-openvpn-server.

That has most (all?) of the tricks you need for a pf-based firewall with Tunnelblick.

@jkbullard

This comment has been minimized.

Copy link
Contributor

jkbullard commented Nov 3, 2016

Tunnelblick itself, and/or installing or uninstalling it, will not affect the utun devices.

It is OpenVPN that creates (and should destroy) the utun devices, and OpenVPN is only run when you connect to a VPN. My guess is that your OpenVPN configuration causes OpenVPN to not destroy the utun device when disconnecting, either because OpenVPN crashes before it deletes the utun device, or you are using "user nobody / group nobody" options in the OpenVPN configuration. If you do that, then OpenVPN is running as nobody when the configuration disconnects, and it is unable to destroy the utun device (which it can only do when it is running as root).

Depending on your setup, "user nobody / group nobody" may also leave bad entries in the routing table, because it can't remove the routes it created. Some configurations don't do any routing, so they don't have this problem.

Thanks for pointing to the pf.conf configuration; I'll take a look at it.

@essandess

This comment has been minimized.

Copy link
Author

essandess commented Nov 3, 2016

Depending on your setup, "user nobody / group nobody" may also leave bad entries in the routing table, because it can't remove the routes it created.

That's exactly what I'm doing in my OpenVPN server configuration file, openvpn-server-tun.tblk/config.ovpn

user nobody
group nobody

I'll have to go off and think about the security implications of changing user and group permissions.

I'll bet the creation of the other utun devices I observed above were created when OpenVPN launched a server using this file.

@jkbullard

This comment has been minimized.

Copy link
Contributor

jkbullard commented Nov 4, 2016

Originally I was thinking you could use a custom "down" script

  • Take Tunnelblick's standard down script (/Applications/Tunnelblick.app/Contents/Resources/client.down.tunnelblick.sh) and modify it to do the additional cleanup that must be done as root. See the OpenVPN documentation for info on environment variables that the down script can use and the arguments it is invoked with. I think the arguments to the down script include the device name that the connection used (such as "utun0"), which would make it easy to delete that device. I don't know about obtaining the routing information, though -- or rather the "unrouting" information.
  • If you use the "openvpn-down-root" plugin (which will be used by Tunnelblick automatically if you agree to that), then the down script runs as root. At some point you may have told Tunnelblick to not use openvpn-down-root; otherwise it would ask you each time you try to connect a configuration with "user nobody / group nobody".

But I am not completely sure that it is OK for the down script to delete the device -- it would not be OK if OpenVPN does anything else with the device, I don't think it does but I don't really know.

As an alternative, you could use a custom "post-disconnect.sh" script that deletes the utun device. The catch there is that that script isn't given any info about the device (or anything else!), so it would have to hard-code the "utun0" or "utun1" or whatever.

Info on using scripts is available at Using Scripts.

Now that I'm thinking about it, maybe Tunnelblick should have an option in it

@essandess

This comment has been minimized.

Copy link
Author

essandess commented Nov 4, 2016

I'll need to debug this step-by-step.

Step 1: Do you know how to figure out what's creating the utun0 interface after a reboot without launching OpenVPN at boot?

@jkbullard

This comment has been minimized.

Copy link
Contributor

jkbullard commented Nov 4, 2016

It's OpenVPN itself that "creates" utun devices; Tunnelblick doesn't have anything to do with them.

Maybe you have a configuration set to connect "when system starts"? So when you restart, it would try to connect that configuration and create utun0.

Even if you don't, see if there is anything that mentions Tunnelblick or OpenVPN in /Library/LaunchDaemons. Maybe something got left there. If so, you can just delete it.

@essandess

This comment has been minimized.

Copy link
Author

essandess commented Nov 4, 2016

Re: pf firewall

Google groups is terrible—my response there was just lost twice, ado I'll post it here.

You'll want to use pf anchors for this. The pf directives will look like:

block all
# Allow OpenVPN
# Refresh with pfctl -a tunnelblick -T load -f /usr/local/etc/tunnelblick-ovpn.conf
anchor 'tunnelblick' label "Tunnelblick OpenVPN Rules"
load anchor 'tunnelblick' from '/usr/local/etc/tunnelblick-ovpn.conf'

The repo osxfortress shows how to build a dynamic firewall using pf anchors and scripts.

This repo uses launchd plists to download open source threat data and update the firewall. It's obvious how to modify the example for your design. See these files:

@jkbullard

This comment has been minimized.

Copy link
Contributor

jkbullard commented Nov 4, 2016

Thanks. It's totally off-topic, but:

I've already received this info two times (and responded once) in private emails that you sent, so there is definitely a problem somewhere. If you haven't gotten my response, here it is:

Thanks. I'll look all this over carefully. I am aware of your work but
didn't remember that it uses pf.

It's probably obvious, but what I'm looking to do is for an OpenVPN
client, not a server, although I do understand that the pf mechanism
is the same either way. I think the main difference is that on a
server you want it to be active at boot and never deactivate, but on a
client you want to be able to activate and deactivate it dynamically.

One basic question: Must I modify pf.conf, or can I do everything via
pfctl? It looks to me like I have to define an anchor in pf.conf (with
directives like you describe) before manipulating it with pfctl, but
I'm really not clear about that. I really hate making modifications to
system files directly because of possible race conditions and
conflicts with other programs that my make modifications to them.

@jkbullard

This comment has been minimized.

Copy link
Contributor

jkbullard commented Nov 7, 2016

That folder (/var/log/Tunnelblick) should be created (if it doesn't exist)
each time Tunnelblick runs its "installer".

That happens when you originally install Tunnelblick, when you install or
modify configurations, or make other changes that require Tunnelblick to
ask for a computer admin's username/password. The folder should be owned by
root:wheel with 0755 permissions.

I assume it's not a permissions problem – Tunnelblick doesn't try to repair
permissions on that folder because it should be the only thing creating it
and it is created by Tunnelblick's "installer" program with the proper
permissions.

On Mon, Nov 7, 2016 at 8:31 AM, Steve Smith notifications@github.com
wrote:

Still digging.

I have a plist net.tunnelblick.tunnelblick.tunnelblickd.plist that dumps
logs to:

StandardErrorPath
/var/log/Tunnelblick/tunnelblickd.log

But the directory /var/log/Tunnelblick doesn't exist. Install bug?


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#340 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAHxKcucv-XwJvhC5FNP-M5VDYqacDZZks5q7yglgaJpZM4KoWxR
.

@essandess

This comment has been minimized.

Copy link
Author

essandess commented Aug 4, 2017

I haven't been able to resolve this on the macOS or Tunnelblick sides, so I just added a bunch of extra rules to pf.conf for robustness in case it happens.

See essandess/macos-openvpn-server@0be941b

@essandess

This comment has been minimized.

Copy link
Author

essandess commented Dec 9, 2018

Following up, unfortunately the fix to #493 doesn't address this issue. Here's what I see with ifconfig -a while running an OpenVPN server with Tunnelblick:

utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
	inet6 fe80::ca26:ff77:5a2a:8019%utun0 prefixlen 64 scopeid 0xe 
	nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
	inet 10.8.0.1 --> 10.8.0.2 netmask 0xffffffff 
utun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
	inet6 fe80::2c03:3e37:c633:5ede%utun2 prefixlen 64 scopeid 0x11 
	nd6 options=201<PERFORMNUD,DAD>
utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
	inet6 fe80::6e78:9f4:5364:ab26%utun3 prefixlen 64 scopeid 0x12 
	nd6 options=201<PERFORMNUD,DAD>
utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
	inet6 fe80::bbcb:aff:bb0b:e94%utun4 prefixlen 64 scopeid 0x13 
	nd6 options=201<PERFORMNUD,DAD>
utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
	inet6 fe80::bee2:1994:fc74:d790%utun5 prefixlen 64 scopeid 0x14 
	nd6 options=201<PERFORMNUD,DAD>
utun6: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
	inet6 fe80::81b4:0775:c99d:a1ec%utun6 prefixlen 64 scopeid 0x15 
	nd6 options=201<PERFORMNUD,DAD>
@jkbullard

This comment has been minimized.

Copy link
Contributor

jkbullard commented Dec 9, 2018

@essandess - Please post the diagnostic info obtained by following the procedure, which is a modified version of the one found at Read Before You Post:

  1. Make sure all Tunnelblick configurations are set to connect manually.
  2. Restart your computer.
  3. (Wait for the computer to completely start up.)
  4. Use ifconfig -a to verify that no utun devices exist.
  5. Open Tunnelblick's "VPN Details" window.
  6. On the "Preferences" tab, please click the button to "Reset Disabled Warnings".
  7. On the "Configurations" tab, please select the configuration you want to connect in the list on the left.
  8. Make sure that "VPN log level" is set to "OpenVPN level 3 - normal output". This is the default setting; higher levels are for debugging OpenVPN itself, which is almost never needed and usually makes it harder to find the cause of a problem.
  9. Click the "Advanced" button; a new window will appear.
  10. Make sure "Keep connected" is not checked.
  11. Close the "Advanced Settings" window.
  12. Click on the "Log" tab.
  13. Click on the "Connect" button.
  14. Wait until the VPN is connected, then wait two minutes more.
  15. Click on the "Disconnect" button and wait until the disconnection is complete. If the disconnection is not complete within 60 seconds, continue anyway.
  16. Click on the "Copy Diagnostic Info to the Clipboard" button.
    Wait for the copy to complete (there is a spinning progress indicator; when it disappears the copy is complete).
  17. Paste into an email or web form.
  18. Remove any sensitive information before sending the email or the form.
@bins90

This comment has been minimized.

Copy link

bins90 commented Jan 9, 2019

可以尝试使用 sudo ifconfig utun(数字序号) down
例如:sudo ifconfig utun1 down
输入个人用户密码确认删除

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment