User -> Tor -> VPN -> Internet - 4.1 broken?

Hey, just installed 4.1 and I can’t get “User → Tor → VPN → Internet” connection working. here is the openvpn log, as you can see, once initialization is completed, a shortwhile later it will timeout due to inactivity. Below is what “ip route show” in terminal shows: via dev tun0 
default via dev eth0 onlink dev tun0 proto kernel scope link src dev eth0 scope host onlink via dev tun0 via dev eth0 

I’m just testing this with cryptofree, but here is the ovpn config I used. auth.txt can contain any username/password. Unfortunately, I can’t upload a cap file from wireshark in sys-tor-vpn on eth0, but essentially it does DNS, TCP/SSL blah blah openvpn connecting, and then once “Initialization Sequence Completed”, there will be a bunch of ARP requests “who has tell” Perhaps someone else who can confirm the same situation, can upload better logs for the rest of us.

Any way to fix this? I’ve tried it with a lot of different free and even a paid VPN but every time, after initialization, it always does the ARP thing and eventually the connection will reset and it’ll do it again etc etc…

To reproduce: create a new/use existing sys-whonix. Create a new appVM with networking set to sys-whonix, and “provides network to other qubes”. use openvpn with any known good configuration.

I’ve found the solution! But unfortunately it isn’t a nice one. After starting openvpn session, we can see output of ip neigh:

bash-5.1# ip neigh show dev eth0 lladdr fe:ff:ff:ff:ff:ff PERMANENT dev eth0  INCOMPLETE

which of course happens because for some reason this ARP request isn’t answered. To fix this, simply execute arp -s IP -i eth0 fe:ff:ff:ff:ff:ff, where IP is the IP address who’s ARP request fails (in cryptofree’s case, it is Then, ip neigh show will output

bash-5.1# ip neigh show dev eth0 lladdr fe:ff:ff:ff:ff:ff PERMANENT dev eth0 lladdr fe:ff:ff:ff:ff:ff PERMANENT

and the ARP requests will stop, and VPN will work just as you’d expect.

Unfortunately, starting the connection everytime, you will probably have to do this. The real question is why does this ARP request fail? There is no easy way to script this either

thank you. fell into this. It helps

This might indeed be a Qubes 4.1 networking bug.

Can someone please report it at ?