rmon.error Failed to add route

[glenna]

Hi.

I am using Ubuntu 16.04 and is using the latest client deb package 8.2R5.
All dependencies is installed.

Still when invoking:
PulseClient.sh -h HOST -u USER -r REALM -U https://URL

The client does bring up the tun0 interface, but when trying to add route, it fails:

rmon.info adding a conflicting route with a lower metric to x.x.x.x/x.x.x.x gw x.x.x.x metric 1 (routemon.cpp:876)
20160927140644.851214 pulsesvc[p9448.t9448] rmon.error Failed to add route: dest x.x.x.x mask x.x.x.x, gw x.x.x.x dev (null). Error 101, fd = 7 (routemon.cpp:981)
20160927140644.851251 pulsesvc[p9448.t9448] rmon.info adding route to x.x.x.x/x.x.x.x with gw x.x.x.x, metric 1, if_id 0 (routemon.cpp:887)
20160927140644.851268 pulsesvc[p9448.t9448] rmon.error Failed to add route: dest x.x.x.x mask x.x.x.x, gw x.x.x.x dev (null). Error 101, fd = 7 (routemon.cpp:981)

I have no idea where to go from here.

Anyone have any ideas?

[zanyterp]

It is not necessarily an error that needs to be tracked; there are instances where this is benign. Is the route one that is needed for your corporate access?
Are you able to complete tunnel setup?
Are you able to access resources without an issue?
What route is not being created?

[glenna]

The tunnel interface is brought up to get the IP/DNS settings, but when trying to get the route it fails and brings the interface down again.
And yes the routes are needed.
Will try and lower the metrics i get on the wifi i am on right now to test.

[zanyterp]

Does this happen with split tunneling enabled and disabled or only enabled?
Can you post the specific route that is failing and, if possible, the one immediately prior and following (e.g. 10.10.10.0/24)?
Does this happen only for Ubuntu clients or on other systems as well?

[glenna]

I have actually found the problem now.
We have clients that we changed the interface name from eth0 to eth1.
And when the pulse client want to be setup it tries to configure eth0, which wont work as it does not exist.
When we changed it back to be named eth0 everything went Ok again.

BUT today we installed some new laptops and did the regular procedure with renaming the interfaces back to eth0 again, but then the tun0 interface instead want to bind to eth1.

It would be great if the client would have a flag to specify what interface it should try and configure instead.

So now i am back to square 1'ish again. As it works on some Ubuntu systems, and on some it don't.

[zanyterp]

Thank you for the update on what is happening and the narrowing down of the trigger. I am not sure why it would try to use eth1; our expectation is for eth0.
For the question on a parameter to force the adapter to use, please contact your account team for an enhancement request
For the switching interfaces, please open a ticket with support so that we can investigate further