Pulse connect VPN exists because unwanted avahi network starts

I missed to system information. Here is it:

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.4 LTS
Release: 18.04
Codename: bionic

# dpkg -l "avahi*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-========================================-=========================-=========================-=====================================================================================
ii avahi-autoipd 0.7-3.1ubuntu1.2 amd64 Avahi IPv4LL network address configuration daemon
ii avahi-daemon 0.7-3.1ubuntu1.2 amd64 Avahi mDNS/DNS-SD daemon
ii avahi-utils 0.7-3.1ubuntu1.2 amd64 Avahi browsing, publishing and discovery utilities

The attachment "avahi-autoipd.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

I'm not sure it makes sense to just universally skip "tun*" interfaces (at least yet) but we may need to review the scenarios in which /etc/network/if-up.d/avahi-autoipd is executing.

Helio: Can you provider a reproducer scenario? e.g. is this ubuntu server, ubuntu desktop, what is the contents of: /etc/network/interfaces, /etc/network/interfaces.d/*, /etc/netplan/* and whether network manager is in use or not. And lastly exactly how pulse VPN is installed and configured, and how that interface is started/connected?

Additionally you may find this issue goes away with netplan versus the older-style interfaces files. In any case with as much info as possible for a reproducer I can check your exact scenario.

This is a ubuntu desktop. A corporate laptop.

> cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

> cat /etc/network/interfaces.d/*
fish: No matches for wildcard “/etc/network/interfaces.d/*”. See `help expand`.
cat /etc/network/interfaces.d/*
    ^

> cat /etc/netplan/*
# Let NetworkManager manage all devices on this system
network:
  version: 2
  renderer: NetworkManager

As you can see this is network-manager based settings.

Pulsesecure is a sort of java browser based application. Since it is a proprietary application, I'm not sure how it runs internally, but it does some basic checkings into your system to allow the connection, and establishes it. It changes all routes to use the VPN as default. Any attempt to change is detect and it considers an attempt to tamper with system, which results in connection drop. That's where the avahi causes the problem.

One extra info: I set the avahi to disable on /etc/default/avahi-daemon.

> cat /etc/default/avahi-daemon
# 1 = Try to detect unicast dns servers that serve .local and disable avahi in
# that case, 0 = Don't try to detect .local unicast dns servers, can cause
# troubles on misconfigured networks
AVAHI_DAEMON_DETECT_LOCAL=0

So even a patch o top of avahi-autoipd that reads this parameter can be enough to avoid this unwanted route to pop up.

Hi @helioloureiro,

While for your use case I can easily see the need for this patch, I'm not sure this should be applied generally. In a VPN split tunnel scenario, the very case that Pulsesecure seems to be rejecting, the original config would probably be more appropriate.

Another path forward - on more recent Ubuntu (hirsute in my case), it appears that avahi-autoipd can be removed without causing excessive other package removals. Would that be a plausible solution for someone with a similar problem?

Hi @dbungert,

Sadly the company decided to move out from pulse secure usage, so I can't help anymore with tests. But I can give some insights.

The main issue is that AVAHI_DAEMON_DETECT_LOCAL set as 0 isn't avoiding avahi to change routes. It shouldn't happen.

My patch isn't this direction and it is much more specific for the use case I had that time. My suggestion for long term solution instead is to just call `return` or `exit 0` once the AVAHI_DAEMON_DETECT_LOCAL value is 0.

What do you think?