Unable to connect to my ISP using NetworkManager

I have an ISP which allows me to connect using a Static IP address. I need to provide the “known” MAC address in my request, which I do through the network configuration. This setup has been working for years, across 3 or 4 replacement machines.

My current machine just gave up and is bricked, so I’ve created a new machine running AlmaLinux 9, which uses NetworkManager to manage the connections.

I have two network interfaces on my machine: One for the local (in-house) network, known as “enp2s0” and one for my ISP (Internet) connection, known as “enp5s0”.

The NetworkManager configuration is different from how I’ve done it before, but I believe I have it all set up correctly. In fact yesterday, I was able to connect to the ISP and get my IP address and had Internet connectivity.

Today, I rebooted the machine and now I can’t get access to the Internet. The “enp5s0” connection appears to come up properly but no access to the Internet.

I spoke with the support folks at the ISP and they said they logged into their “gateway” device (the demarkation device at my house which connects their fiber cable to an RJ45 network cable, which is plugged into my machine. They said they can see the link is active, but no attempt to negotiate with it from my machine.

I unplugged the wire and plugged it back in and they confirmed the link went inactive and then back to active.

I set the logging level for Network Manager to TRACE and got the output after attempting to bring the connection up, but I don’t see any errors in there. It appears to come up successfully.

I depend on this Internet connection for my work and I’m really stuck. Can anyone please suggest what I can try? I’m not sure what information you may want so I’ll stop here.

It would be nice to know the state of things (but obviously you can’t copy-paste yet).

For comparison, I show a sample:

# systemctl status NetworkManager
● NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2024-04-15 16:22:44 EEST; 2 weeks 3 days ago
     Docs: man:NetworkManager(8)
 Main PID: 111211 (NetworkManager)
    Tasks: 4 (limit: 608541)
   Memory: 14.5M
   CGroup: /system.slice/NetworkManager.service
           ├─111211 /usr/sbin/NetworkManager --no-daemon
...


# nmcli d s
DEVICE        TYPE      STATE         CONNECTION    
brman         bridge    connected     bridge-brman  
eno1np0       ethernet  connected     eno1np0       
eno4          ethernet  connected     br-slave-man  
eno2np0       ethernet  disconnected  --            

# nmcli c s
NAME           UUID        TYPE      DEVICE       
bridge-brman   7701..7ff7  bridge    brman        
br-slave-man   5e10..d407  ethernet  eno4         
eno1np0        26ca..3f54  ethernet  eno1np0      
eno2np1        f483..0fd8  ethernet  -- 

We see that NetworkManager is up and that system has three physical NIC. One of them is not in use. There are also connections defined for all of them, but one is not enabled. I seem to have that on defaults (except connection.autoconnect):

# nmcli -f 802-3-ethernet,ipv4,connection.autoconnect c s eno2np1
802-3-ethernet.port:                    --
802-3-ethernet.speed:                   0
802-3-ethernet.duplex:                  --
802-3-ethernet.auto-negotiate:          no
802-3-ethernet.mac-address:             --
802-3-ethernet.cloned-mac-address:      --
802-3-ethernet.generate-mac-address-mask:--
802-3-ethernet.mac-address-blacklist:   --
802-3-ethernet.mtu:                     auto
802-3-ethernet.s390-subchannels:        --
802-3-ethernet.s390-nettype:            --
802-3-ethernet.s390-options:            --
802-3-ethernet.wake-on-lan:             default
802-3-ethernet.wake-on-lan-password:    --
802-3-ethernet.accept-all-mac-addresses:-1 (default)
ipv4.method:                            auto
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         --
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.routing-rules:                     --
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
ipv4.dhcp-client-id:                    --
ipv4.dhcp-iaid:                         --
ipv4.dhcp-timeout:                      0 (default)
ipv4.dhcp-send-hostname:                yes
ipv4.dhcp-hostname:                     --
ipv4.dhcp-fqdn:                         --
ipv4.dhcp-hostname-flags:               0x0 (none)
ipv4.never-default:                     no
ipv4.may-fail:                          yes
ipv4.required-timeout:                  -1 (default)
ipv4.dad-timeout:                       -1 (default)
ipv4.dhcp-vendor-class-identifier:      --
ipv4.link-local:                        0 (default)
ipv4.dhcp-reject-servers:               --
connection.autoconnect:                 no

(This is Alma 8; Alma 9 options are not 100% same.)


I take it that the DHCP of ISP is configured to hand out predetermined IP address to one specific MAC-address (and nothing to anyone else). They could probably update their config to use your current MAC but if NM does not even call the DHCP server, then that would not help.

Which options have you modified?

Thank you for responding. I spent a lot of time yesterday troubleshooting. What I’ve found is that when I reboot the machine and both network interfaces are brought up, the external interface (enp5s0) - which connects to my ISP - doesn’t work. I don’t get any errors in the logs, just no attempt to connect to the ISP.

If I just stop the internal interface and start it again, then everything works.

There seems to be a timing issue between the two interfaces - or there is some aspect of their configurations which is interfering with each other.

Here is the nmconnection file for my internal network:

[connection]
id=enp2s0
uuid=8bf91897-b121-3fee-9791-88f8a8ceaf83
type=ethernet
autoconnect-priority=-999
interface-name=enp2s0
timestamp=1714591413

[ethernet]

[ipv4]
address1=10.1.1.1/24,10.1.1.1
dns=10.1.1.1;
dns-search=mehconsulting.com;
method=manual

[ipv6]
addr-gen-mode=eui64
method=disabled

[proxy]

Here is the nmconnection file for my external network:

[connection]
id=enp5s0
uuid=e646d8aa-921d-43fe-bd5a-48ff7df4c235
type=ethernet
interface-name=enp5s0
timestamp=1714679025

[ethernet]
cloned-mac-address=00:40:F4:04:C8:3C

[ipv4]
address1=65.78.188.61/24,65.78.188.1
dhcp-client-id=01:00:40:F4:04:C8:3C
dhcp-hostname=00:40:F4:04:C8:3C
dns=72.22.1.7;
method=manual

[ipv6]
addr-gen-mode=eui64
method=disabled

[proxy]

Assuming this is a timing issue, is there a way to get the Network Manager to delay the starting of the internal network? or perhaps getting it to order the way they are started?

Timing should not make a difference, but perhaps it does in your case.

You have manual IPv4 config; the system has no need to negotiate with anyone. What if you switch ipv4.method to ‘auto’? That should call to DHCP, i.e. attempt to negotiate. (Whether DHCP of ISP does hand out config for you is a followup question.)


If this system is a desktop, then one could have enp5s0 with autoconnect ‘no’ and enable it explicitly after boot.


man nm-settings does list connection.wait-activation-delay and connection.wait-device-timeout. Not sure whether they could help.

The connection.wait-activation-delay says it’s the time in ms before the connection is considered activated. It doesn’t seem to delay when the connection is brought up.

I’ve always had the connection set up as manual (static, not DHCP) and they only give me the IP address if I send them the MAC address - it’s their way of making sure I’m who I say I am before they give me a connection.

The tech said that when I brought up my connection, he saw no activity on their gateway, which they normally would. When I switch their cable to my laptop (and configured it for a connection to them), then he saw the connection.

If I set my connection to ‘auto’, then NM also add DNS stuff to the resolv.conf file, which I don’t want (I have my own bind service). If I leave it set to manual, then the connection comes up and works as it has before.

The only problem is this timing issue when booting the machine.

I was thinking about creating an rc.local script which just does a delay for a few seconds and then brings the local connection down and back up again and see if this works.

Is it possible there is a conflict between the two network configurations which is causing this issue? I would love to solve it in a non-hack way :slight_smile:

Ignoring the DNS issue, does it get the correct address, and also on boot?


Set ipv4.ignore-auto-dns yes and then “DNS stuff” from DHCP is not used.


The rc.local is deprecated. If one has to do something like that, then one creates systemd unit(s), possibly a “oneshot” that is activated by “timer”.

Thanks for that. I’ve set ipv4.ignore-auto-dns to true, ipv4.method to auto and removed the dhcp settings in the configuration. The Internet connection is still working, but I’m still running into the issue after reboot where the Internet connection is not getting set up.

To make the Internet connection (enp5s0) to work after a reboot, I must stop and restart the local area connection (enp2s0).

Does anyone have any ideas about how to get this to come up automatically after reboot?

Why would local affect …

Wait! This:

I’m not used to reading the files. How does nmcli describe that?

nmcli -f ipv4 c s enp2s0

This shows:

ipv4.method: manual
ipv4.dns: 10.1.1.1
ipv4.dns-search: mehconsulting.com
ipv4.dns-options: –
ipv4.dns-priority: 0
ipv4.addresses: 10.1.1.1/24
ipv4.gateway: 10.1.1.1
ipv4.routes: –
ipv4.route-metric: -1
ipv4.route-table: 0 (unspec)
ipv4.routing-rules: –
ipv4.replace-local-rule: -1 (default)
ipv4.ignore-auto-routes: no
ipv4.ignore-auto-dns: no
ipv4.dhcp-client-id: –
ipv4.dhcp-iaid: –
ipv4.dhcp-timeout: 0 (default)
ipv4.dhcp-send-hostname: yes
ipv4.dhcp-hostname: –
ipv4.dhcp-fqdn: –
ipv4.dhcp-hostname-flags: 0x0 (none)
ipv4.never-default: no
ipv4.may-fail: yes
ipv4.required-timeout: -1 (default)
ipv4.dad-timeout: -1 (default)
ipv4.dhcp-vendor-class-identifier: –
ipv4.link-local: 0 (default)
ipv4.dhcp-reject-servers: –
ipv4.auto-route-ext-gw: -1 (default)

Is it the connection.autoconnect-priority? This makes it sound like it will only select one of the connections, based on the priority. Is it possible this is why the enp5s0 is not working?

The autoconnect-priority in enp2s0 is -999, while the property is not set in enp5s0, which means it defaults to zero.

Just as I suspected. This is the most likely reason for your problems. Remove the bogus route:

nmcli c mod enp2s0 ipv4.gateway ""

Awesome! That was it. Now the machine reboots and both interfaces come up and work as desired.

I can’t express how much I appreciate the time you’ve taken with me on this. It was a real head-scratcher!

I should have spotted it quicker.

The issue was that your config did add a second “default route” – via “router” at address 10.1.1.1. It is quite frequent mistake to add “gateways” for each connection, while logically machine can have only one default route and thus should not have the additional stuff.

What does baffle me is why the boot did give higher priority to the “lan” default route, but down&up did drop it below the default route that “wan” has.