I am using a PC which has two NICs for two different Sub-C nets:
One for the local LAN
one for the internet router.
It worked well under Fedora for some years, but since a few months it is almost no more usable.
With both being plugged in, it takes a long time to connect to a network drive in the local LAN, but no internet connection is available. Unplugging the LAN, internet connection works. Plugging LAN again it takes roughly a minute to connect to the LAN.
Then it may be possible to use both without noticeable delays, but that does not always work.
Unfortunately I did not notice from which on the problems started: F32 â F33 update or since a newer kernel version. The PC was updated regularly.
It could be, but frankly speaking I do not fully understand the entire description.
If it was a change made in Fedora 33, so it may fit to the time when the âproblemâ started.
If you do not wish to use systemd-resolved, then manual intervention will be required to disable it:
Disable and stop systemd-resolved.service.
Delete /etc/resolv.conf
Restart the NetworkManager service. NetworkManager will then create a traditional /etc/resolv.conf. (If you are not using NetworkManager, you may create your own /etc/resolv.conf and configure it to your liking.)
That may be worth a try, but will systemd-resolved be used in the coming Fedora versions too and the problem then comes back?
We arenât planning on making it mandatory, so if you follow the above steps, that should persist. Also, if it does solve the problem, please file a bug because this use case should be supported.
# let the system know NetworkManager is back in charge
...
sudo rm /etc/resolv.conf
sudo ln -sf /run/NetworkManager/resolv.conf /etc/resolv.conf
...
# to prevent the service from being enabled without consent
...
sudo systemctl disable systemd-resolved.service
sudo systemctl mask systemd-resolved.service
...
Made an upgrade to 5.11.9 this morning and rebooted a few times.
Both are plugged in: The first access to a network drive needs some seconds but then the access is as quick as to a local drive.
It is not possible to access a web site
I have run the 4 commands , but the the problem is still there.
I have to unplug LAN after boot to use the internet, and after first use, LAN can be plugged in again to use both.
Well, in total there sould have been 6, but a reboot did the rest anyway
AFAIK /etc/resolv.conf linking to NetworkManager was the default up to f33 so âold schoolâ tools like nslookup should work again.
If network resolution seems not to be the problem, maybe your routing table can shed some light to this.
Providing the output of
route
nslookup fqdn.of.your.router
nslookup fqdn.of.your.nas
# or the same with dig
dig fqdn.of.your.router
dig fqdn.of.your.nas
might help.
If the name-resolution via nslookup/dig works, itâs time to look elsewhere. Also the routing-table should reflect your network, providing entries for both your nicâs.
dig fritz.box
...
;; QUESTION SECTION:
;fritz.box. IN A
;; ANSWER SECTION:
fritz.box. 60 IN A 192.168.178.1
...
;; SERVER: 192.168.333.1#53(192.168.333.1)
...
âŠor like this for the reverse lookup.
nslookup 192.168.178.1
1.178.168.192.in-addr.arpa name = fritz.box.
dig -x 192.168.178.1 # <- you have to set -x for a reverse lookup!
...
;; QUESTION SECTION:
;1.178.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
1.178.168.192.in-addr.arpa. 60 IN PTR fritz.box.
...
;; SERVER: 192.168.333.1#53(192.168.333.1)
...
Using dig to querry for an ip instead of an fqdn (without the -x) will cause the dns server to treat the ip like an fqdn he canât resolve, querry his root-servers and fail. But it shows that in your case 192.168.178.5 is the dns-server your host is using for dns-resolution.
In any case 192.168.178.5 does not have any dns informaton for your network it seems.
So you should either set the correct dns-server via dhcp or directly via /etc/resolv.conf, or make sure the dns-server has the appropriate information.
If 192.168.178.5 is the host itself, systemd-resolved still is active and not using the dns-server for your networkâŠ
dig cannot return any usable information on a private subnet. 192.168.0.0/16 is a private subnet so all parts are blocked from dig.
You really should only have one default route, and that should point to the device that leads to the internet. Having 2 default routes leads to trouble, especially since this one âdefault _gateway 0.0.0.0 UG 101 0 0 enp0s31f6â leads to the LAN
I have this
0.0.0.0/1 via 10.203.7.1 dev tun0
default via 192.168.2.1 dev wlp4s0 proto dhcp metric 600
10.203.7.0/24 dev tun0 proto kernel scope link src 10.203.7.8
128.0.0.0/1 via 10.203.7.1 dev tun0
192.168.2.0/24 dev wlp4s0 proto kernel scope link src 192.168.2.111 metric 600
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
when I have my vpn connected, but notice the metrics. The tunnel has no metric (metric 0) and my default route via the gateway router has metric 600 so it chooses the lowest metric first (tun0).
I fully agree on that, but since the routing table is set by the system (I guess ?) thatâs what we have to work with ATM. In theory if two routes for the same destination use different nics, the metric decides which one to try first. But since there is no connecton to the internet via the LAN-interface (?), the other route is used.
enp0s31f6 - 192.168.13.1 - is a NAS in the local LAN
enp13s0 - 192.168.178.5 - is a Router with firewall, connected to a FritzBox in Bridging mode.
enp0s20f0u5u1u2 - 192.168.167.0 - a programmer
enp13s0 - DSL: Gateway and DNS set to 192.168.178.5
enp0s31f6 and enp13s0 have static IP adresses
route -n
0.0.0.0 192.168.13.1 0.0.0.0 UG 101 0 0 enp0s31f6
0.0.0.0 192.168.178.5 0.0.0.0 UG 102 0 0 enp13s0
192.168.13.0 0.0.0.0 255.255.255.0 U 101 0 0 enp0s31f6
192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0
192.168.167.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s20f0u5u1u2
192.168.178.0 0.0.0.0 255.255.255.0 U 102 0 0 enp13s0
192.168.178.0 192.168.178.5 255.255.255.0 UG 102 0 0 enp13s0
@benpack, customize the gateway configuration as follows:
nmcli connection modify id LAN \
ipv4.never-default yes ipv6.never-default yes
nmcli connection up id LAN
@computersavvy, the netmask takes precedence over the metric.
The metric matters if the routes have the same netmask.
Your case is the former, while the OPâs is the latter.