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