I use Mullvad vpn. Normally, once “local network sharing” is enabled in the app, I could keep Mullvad connected when I used a virtual machine for my work. The VM guest traffic was properly routed through Mullvad, which is only installed on the host machine.
Just in the past couple of weeks, I need to disconnect Mullvad in order to have Internet connectivity in my VM guest. I would like to get things back to the previous behavior.
I’ve reached out to Mullvad also, but no solution there yet.
How do you connect the VM ? Via libvirt NAT or bridge?
Via NAT, libvirt takes care of forwarding and masquerading, so packets should go out along the at that moment highest priority default gateway, VPN. Should just work.
With bridge, you go from the firewalld zone assigned to bridge to the zone assigned to VPN,
so it’s your responsibiliy to setup forwarding policies and masquerading.
So question in that case is whether you have changed something in firewalld config with this as side effect?
A way to start is to set firewall-config runtime LOG_DENIED=ALL, follow syslog with “journalctl -f”, start connection from VM and check for firewall related messages.
Thanks for the reply.
Connection is the default libvirt NAT. It did “just work”, for the last couple years, but now it’s not.
I have not touched my firewalld settings in recent times.
Unfortunately, the troubleshooting step you outlined is a bit beyond me.
This means that traffic from virbr0 with source address 192.168.122.0/24 is allowed to be forwarded, and related/established traffic to virbr0 and to address 192.168.122.0/24 is allowed.
Everything else is blocked, so you have a safe firewall between the VM and rest of the world, including LAN.
Everything with source address in the 192.168.122.0/24 range will get the source address of the outgoing interface, wherever it may go.
In this configuration, I’ve a VM with Protonvpn up, and a traceroute shows that it works as desired.
May be you can try the two sudo iptables commands and see whether you get similar output in the listing.
In addition, you can check routing:
#Without VPN
ip route get 1.1.1.1 from 192.168.122.1
1.1.1.1 from 192.168.122.1 via 192.168.2.254 dev bridge0 uid 0
cache
#With VPN
ip route get 1.1.1.1 from 192.168.122.1
1.1.1.1 from 192.168.122.1 via 10.96.0.1 dev tun0 uid 0
cache
That’s fine. So the virbr0 interface is connected to the correct zone. Then sorry, I do not know how to debug this further by forum. May be someone else has idea’s.
On my F40 system, a VM connected via NAT takes the normal way without VPN and the VPN route with a (free) ProtonVPN connection enabled.
The nslookup and ping results are functioning , whether the vpn is on or not. Still there is no Internet connectivity via a browser or trying to check for upgrade on guest system, etc.
Good idea to check DNS. There is one thing which worries me. The libvirt starts the “dnsmasq” program which is a DNS cache and DHCP server. The cache implies that if you lookup only example.com, once found it will always find example.com until cache expires.
It would be interesting to know what a real life internet connection gives as error message,
so with VPN on e.g. “sudo dnf --refresh update” in a terminal.
The counter just reached zero: in my configuration with my ISP’s DNS servers, example.com has a lifetime of currently 3266 seconds in cache.
So ping to 1.1.1.1 and 8.8.8.8 works, so there is a sign of connectivity. If DNS fails, one would expect messages that servers cannot be found, from your response I assume dnf just hangs.
Alternative e.g. “curl https://google.com” should output some html code.
What is the protocol used? I’ve seen Mullvad uses Wireguard with Linux. I’ve tested only OpenVPN now, but in theory this should not make difference. If Wireguard, what is the output of command
“sudo wg” with public key an peer id obfuscated?
Just a wild guess: are there Mullvad extensions active like multihop which could confuse the NAT connection tracking?
Edit: should not happen, For normal connection too any packet is identified by source address/port and destination address/port.
I assume internet from VM host is working flawless via VPN.
Go to Settings --Network – VPN – your connection – open check it is ipv6 method set to automatic if yes disable it save and try to use internet to your vm
I just checked the Mullvad wireguard “obfuscation” setting. If automatic or off, I have no Internet in my VM. If on, I do have Internet in my VM.
I’ll attempt to repeat my results and will inform Mullvad.
Here is Mullvad’s note on obfuscation:
WireGuard out of the box works only over UDP. This can cause problems because UDP is blocked on many public networks like in cafes and on trains. If that happens then you can set Obfuscation to On (UDP-over-TCP).
Note that using WireGuard Obfuscation (UDP-over-TCP) can significantly increase the latency and also slow down the Internet speed. So if you don’t need it then do not turn it on.
So, I have no idea why my VM internet was working fine until recently, but it seems at least that we’re closing in on the cause.
Thank you all for your help with the troubleshooting! I didn’t know if it was an issue with QEMU or Mullvad but at least I have a workaround and a point of discussion with Mullvad.
Interesting, please let know what’s Mullvad response is. Wireguard is UDP only, so some tunnel mechanism should be used to encapsulate this in TCP. OpenVPN has this option natively. But at the very end, one would expect the same output on the Wireguard interface, so why this interference with the libvirt NAT ???
ping works, so this extra encapsulation could be a MTU, maximum transmission unit, issue but why only on the VM?
Something to study. The only thing I can say is that I have no problem with VM and openvpn/tcp to protonvpn. Unfortunately, they only support Wireguard/tcp on android.
The wireguard developers explicitely state to support only udp because tcp in tcp can lead to exploding timeouts. But VPN providers like to mimic the VPN as HTTPS traffic.
The tcp-mss-clamp rich rule lands in a forward rule, so apparently this is only to fix some device behind the Linux system including a VM in this case.
And I’ve to check why much bigger MSS TCP packets are in Wireshark while ethool shows offloading off. Unless the driver fools me by assembling bigger packets from mtu size ones.
it is check box to use other users