On Sat, 2019-02-02 at 21:50 +0800, Ed Greshko wrote:
On 2/2/19 8:22 PM, Patrick O'Callaghan wrote:
Last ditch left-field idea: I have a (commercial) VPN service which is not normally turned on but does have a systemd daemon running. I turned it off and everything started working.
I am now looking at 3 Fedora guests and a Windows guest all connected and even able to ping each other.
I think the VPN daemon was messing with the firewall. I'll have to see what to do about that but for now, it looks like this was the culprit all along. Who knew?
Apologies for wasting everyone's time, but maybe there's a lesson here somewhere ...
Well, it would be good to....
Stop firewalld, dump the IPTables, start the VPN daemon, wait a bit, and dump the IPTables again.
I didn't stop firewalld, but iptables with and without the VPN show no difference. Hypothesis: the problem occurs when the guests start *after* the VPN daemon is running (it comes up at boot time), but if I start the guests first then it works. I'll try and get round to testing this when I have time.
Also, it would be helpful to actually name the commercial VPN which may warn others about the pitfall.
ExpressVPN.
But, it is good to know it is fixed. And yes, the lesson is "list things you've installed that aren't part of the normal distribution".
Indeed, but for most people that would be a long list.
The other thing that I'd question would be: If you'd made no changes why then did the problem arise? Did a change in some Fedora component become "incompatible" with the VPN daemon?
Ay, there's the rub. Both libvirt-libs and the ExpressVPN rpm date from last October.
poc