Discovery fails behind VPN network lock

[eidermar]

First off thanks for generously sharing your work with us. Second, this is not really a bug report but rather an attempt to get two things to work together properly.

I just lately installed this plugin https://github.com/sanghviharshit/script.kodi.lifx.ambilight for my Kodi installation on Ubuntu. It uses lifxlan to communicate with the LIFX bulbs. Now I do have a VPN client running on this server that uses IP-table rules to offer a feature called network lock (Leak protection). Unfortunately as soon as I activate the network lock feature the bulb discovery by lifxlan fails. My technical background is not good enough to understand why this is happening. I was told something about DNS and hostnames being probably responsible for the issue but have no idea what to do with that information tbh.

If you have any idea what causes this behavior and even better a possible hint for a solution I'd be very grateful.

[mclarkk]

What VPN client are you using? I'd like to look up more information about your specific client's network lock feature, but it's difficult without knowing the brand.

I can't speak to the rest of the Kodi plugin, but lifxlan doesn't rely on DNS or hostnames at all. It does rely heavily on broadcast messages over the LAN. That means the device running lifxlan and the LIFX bulbs need to be sending/receiving messages on the same local network. I'm guessing that the VPN client is messing up the whole local broadcast paradigm.

If that's the problem, it should be fixable. I've been reading up on the network lock features for VPN clients in general, and it looks like with most clients there is an option to configure where LAN traffic goes. Once I know more about which client you're using, I can be more helpful in pointing you towards more concrete solutions.

[eidermar]

Thanks for your quick reply.

I'm using AirVPN's Eddie Client. https://airvpn.org/faq/software_lock/ and https://airvpn.org/software/

There's is a feature that says allow LAN traffic for the network lock but unfortunately that doesn't help and putting a bulb's local IP address into the allowed routes doesn't either.

Thank you for looking into this!

[mclarkk]

For sure! Could you post your iptable rules? If you don't want to post the whole thing, in particular I'm interested in any rules about 255.255.255.255, which is the broadcast address, and any LAN rules (192.168.0.0, 10.0.0.0, etc.).

[eidermar]

Here you go: https://paste.ubuntu.com/23176687/

[mclarkk]

Thanks! I don't see anything obviously wrong, but then I'm also not an expert on iptables or VPNs.

I'm currently in Germany for a conference, and a couple days after I get back I have a paper deadline, and then a couple of days after that I have an important presentation, so I won't be able to look at this in-depth until the 24th. In the meantime, I think the AirVPN forums would be a much better place to get help -- apparently they see many issues about LAN communication failing with network lock enabled, and they'll be able to understand how your configuration is interacting with AirVPN.

The most helpful thing I can do for you now in your quest to get help from the AirVPN folks is to tell you that the lifxlan discovery protocol uses the LAN broadcast address 255.255.255.255 and doesn't rely on DHCP or DNS.

Also, have you tried just creating a Light object directly from IP/MAC address? Does that work, or is it just discovery that's not working?

[eidermar]

Don't worry. There are more important things than light bulbs :-)

I will try to get some support from the AirVPN guys and keep you updated. I'll also have to look into the light object from IP process.

Good luck with your presentations!

[eidermar]

I promised to update you on the issue. Well, after going back and forth with AirVPN's support the issue is still unsolved. They claim it has nothing to do with there service and I have to work this out some other way. Well, and maybe just maybe they are right!?

The strange thing is after testing this on 3 different machines and 2 operating systems the results are very inconsistent to say the least. At first I was comparing my two main machines in regards to the AirVPN client and this is what came out:

OSX:

AirVPN client not started -> lifxlan works
AirVPN client started, network lock ACTIVE, not connected to AirVPN -> lifxlan fails
AirVPN client started, network lock ACTIVE, connected to AirVPN -> lifxlan fails
AirVPN client started, network lock NOT ACTIVE, connected to AirVPN -> lifxlan works

AirVPN client not started, AirVPN connected via Tunnelblick -> lifxlan WORKS

UBUNTU:

AirVPN client not started -> lifxlan works
AirVPN client started, network lock ACTIVE, not connected to AirVPN -> lifxlan works
AirVPN client started, network lock ACTIVE, connected to AirVPN -> lifxlan fails
AirVPN client started, network lock NOT ACTIVE, connected to AirVPN -> lifxlan fails

AirVPN client not started, AirVPN connected via Network Manager -> lifxlan FAILS

And to add to the confusion I just recently did some tests on my MacBook Pro and guess what? - lifxlan didn't work no matter what. Didn't matter if It was connected to AirVPN / OpenVPN with/wthout network lock or not at all. Also, on another machines it's working via Ethernet but not via WiFi etc., etc.

So maybe it's not a AirVPN/OpenVPN problem after all but some other broadcasting/networking issue? But I even changed routers, turned off all firewalls, disabled everything I could think of that could interfere with the broadcasting packages to no avail.

I'm out of ideas, and have pretty much given up on this. I just thought I'll update you in case you have some final idea based on my test descriptions.

[mclarkk]

Hey, thanks for getting back to me! That sounds frustrating. Could you post the specific errors and ways that lifxlan is failing under these conditions? Thanks!

[eidermar]

Of course. As I'm not a coder my "test scenario" was supposedly simple and amateurish. I installed lifxlan on all machines and ran the blink_all.py from your examples folder from terminal repeatedly while changing the VPN setup. "Failed" in this case means no communication with the bulbs happened and the following error message was thrown:

Discovery will go much faster if you provide the number of lights on your LAN:
  python /Users/XXX/Desktop/lifxlan-master/examples/blink_all.py <number of lights on LAN>

Discovering lights...
Traceback (most recent call last):
  File "/Users/XXX/Desktop/lifxlan-master/examples/blink_all.py", line 81, in <module>
    main()
  File "/Users/XXX/Desktop/lifxlan-master/examples/blink_all.py", line 21, in main
    original_powers = lifx.get_power_all_lights()
  File "/usr/local/lib/python2.7/site-packages/lifxlan/lifxlan.py", line 60, in get_power_all_lights
    responses = self.broadcast_with_resp(LightGetPower, LightStatePower)
  File "/usr/local/lib/python2.7/site-packages/lifxlan/lifxlan.py", line 203, in broadcast_with_resp
    raise WorkflowException("Did not receive {} in response to {}".format(str(response_type), str(msg_type)))
lifxlan.device.WorkflowException: Did not receive <class 'lifxlan.msgtypes.LightStatePower'> in response to <class 'lifxlan.msgtypes.LightGetPower'>

I thought that maybe there maybe was a problem with broadcasting and network interfaces after reading these posts: https://superuser.com/questions/335263/problem-playing-games-using-openvpn-that-use-broadcast-packets-other-games-work
But that was a wild guess and way over my head.

Strange thing is the Macbook Pro that was unable to communicate with the bulbs even when not connected to a VPN at all. I don't know how that fits into the picture. Please ignore this. It seems that this specific machine has some general networking problems not related to this issue.

[eidermar]

I was able to solve to problem. As far as I can tell after investigating with wireshark the problem was that the bulbs and the computer were sending their broadcast packages on different network interfaces. By forcing 255.255.255.255 outside the VPN tunnel this was resolved. Now everything seems to be working perfectly.

[mclarkk]

That's wonderful! I'm glad you were able to figure it out, and thanks for sharing the solution here!