Since interface with this name is present then it should be somewhere in the log.
You can search for a string in journalctl with / key. For example, type /ens6 and then press Enter.
You can read journalctl help about its shortcuts if you press h key.
1 Like
I tried typing the command but without success, so I did a search from the terminal toolbar.
kernel: r8169 0000:00:06.0 ens6 : No native access to PCI extended config space, falling back to CSI
ens6: Link is Down NetworkManager: device(ens6) :. state change: unavailable → unmanaged(reason ‘sleeping’ , sys-iface-state:‘managed’)
The following messages are picked up from the lines that appeared in ens6 that seem to be important.
How did you configure your network interface? Is it using DHCP or is it configured manually?
If it’s DHCP then can you try to configure it using manual method?
1 Like
Just these messages are not enough to understand what is happening there. If I could see the full log maybe I could think of a possible issue but with just these messages I have no clues.
1 Like
Yes, I tried with DHCP and specified manually, I did not change the settings for PFSense either, I am still using DHCP, the DHCP range is also set to 192.168.1.10 - 192.168.1.245, I have not changed the settings for PFSense, I am still using DHCP.
Can you copy the sys-net log and upload it here?
You can write the log in file in sys-net terminal with this command:
sudo journalctl -b > logfile
1 Like
I didn’t know how to export the logfile, so I pasted it into a text editor and brought it here. it has a yaml extension, but I think you should change the extension to txt.
Did you copy a full log?
I don’t see these messages there:
1 Like
Apologies. I had closed Terminal with the log and saved another one. It should be listed here.
Interfacelog_2.yaml (57.6 KB)
I managed to get them back on board! Using this thread as a reference,
I tried this command and checked the connection with DHCP,
I deleted all the other sys-net files I had created and did a Restart, and was able to get the net connection back. Thank goodness.
Thank you, APPARATUS, for your long hours of help. Now I can resume the PFSense DoH/DoT implementation again!
Be aware that permissive=true option has a downside:
NOTE: The permissive flag increases attack surface and possibility of side channel attacks. While using the no-strict-reset flag, do not require PCI device to be reset before attaching it to another VM. This may leak usage data even without malicious intent. Both permissive and no-strict-reset options may not be necessary and you should try one first, then the other, before using both.
I’d suggest you to first try to use just no-strict-reset=true option:
Get your network card DEVID from the output of this command in dom0 terminal:
qvm-pci ls | grep sys-net
Then run the commands below in dom0 terminal but replace xx_xx.x with DEVID of your network card:
qvm-pci detach sys-net dom0:xx_xx.x
qvm-pci attach -o no-strict-reset=True --persistent sys-net dom0:xx_xx.x
If it won’t work then try to use pci=nomsi kernel option for sys-net:
And only use permissive=true as your last resort if nothing else works.
1 Like
Thank you very much.I got a command not found with qvm-pcils, and I was trying to see if there was some other command,
qvm-pci | grep sys-net
I was able to extract sys-net here. dom0:09_00.0, seems to be my ethernet ID.
As for detaching the devices registered by sys-net, I did it one by one.
qvm-pci detach sys-net
and then
‘qvm-pci attach -ono-strict-reset=True --persistent sys-net dom0:09_00.0’
This successfully registered them again.
I would like to ask you one question: you say that there is a risk of side-channel attacks with the settings you have made this time, but what would an attacker be targeting? This time, I registered an Ethernet device, but was there a vulnerability in the LAN itself?
Actually I was wrong and the best way to try and fix the problem sorted by lowering your security would be this:
pci=nomsi kernel option (most secure) > no-strict-reset=True > permissive=true > permissive=true + no-strict-reset=True (least secure)
no-strict-reset=True has security risk as well, but less than permissive=true.
More info about it here:
In case device reset is disabled for any reason, detaching the device should be considered a risk. Ideally, devices for which the
no-strict-resetoption is set are attached once to a VM which isn’t shut down until the system is shut down.
Additionally, Qubes restricts the config-space a VM may use to communicate with a PCI device. Only whitelisted registers are accessible. However, some devices or applications require full PCI access. In these cases, the whole config-space may be allowed. You’re potentially weakening the device isolation, especially if your system is not equipped with a VT-d Interrupt Remapping unit. This increases the VM’s ability to run a side channel attack and vulnerability to the same. See Xen PCI Passthrough: PV guests and PCI quirks and Software Attacks on Intel VT-d (page 7) for more details.
1 Like
Thank you. I found it very helpful to know that the security risk also changes depending on the options when attaching the device.
I also found out about side-channel attacks, that the risk is different depending on whether the connection between the OS and the device is towards being tighter and stricter, or looser and ‘anyone can use it’…
If you’re up to it (no pressure) I think that listing for those three options, what they do and what threat using them (or not) is meant to mitigate would be a valuable piece of shared knowledge in itself. (Asking for a friend! 
)
1 Like
And I have one additional note. My Debian did not come with a dig command, but a moderator used a tool called Doggo, which I will install and use for verification.
You can install dig in debian with this command:
sudo apt install dnsutils
ありがとう、インストールできました。いまのところ、PFSenseは1.1.1.1/1.0.0.1のDNS設定、QubesOS側も1.1.1.1/1.0.0.1（ポート53で通信）の設定で通信ができている状態ですが、これを10.139.1.1/10.139.1.2にnameserverを変更した上でdigをしてみました。
画像のとおり、10.139.1.1のところで接続が止まっているようです。おそらくこのアドレスはQubesOSの内部DNSで使われているものだと思うのですが、こちらで何か問題が発生しているのかもしれません。
The Qubes OS virtual DNS servers 10.139.1.1/10.139.1.2 are used by qubes and they are redirected to real DNS servers in sys-net using firewall rules.
So in the end the qubes are using DNS servers that are set in sys-net.