Two NICs, a Lost Static Address, and a Firewall Rule That Vanishes

The address was applied with ip, which touches only the running kernel. NetworkManager never learned about it, so the next boot brought up the 'ens4' profile with method auto and no address appeared.

nmcli connection modify ens4 \
  ipv4.method manual \
  ipv4.addresses 10.20.0.5/24 \
  ipv4.gateway "" \
  ipv4.never-default yes \
nmcli connection up ens4
ip -4 addr show dev ens4 ; ip route

Judgement points:

• ipv4.method manual is required; leaving it auto means NM keeps trying DHCP on a segment with no DHCP server.
• An empty ipv4.gateway plus ipv4.never-default yes guarantees ens4 never installs a second default route. Two default routes is the usual cause of 'the internet works sometimes' on multi-homed hosts.
• Prove persistence from the saved profile, not from the live state:

nmcli -p connection show ens4
cat /etc/NetworkManager/system-connections/ens4.nmconnection   # root only
test -f /etc/NetworkManager/system-connections/ens4.nmconnection && echo saved

Anything configured only with ip will not appear in that file, and nmcli connection show shows the saved values rather than the live device.

firewall-cmd --add-port=8080/tcp without --permanent writes to the runtime configuration only. The running firewall immediately honours it, which is why it 'worked' for two weeks - and firewall-cmd --reload, a reboot, or the firewalld restart during the weekly maintenance wipes it back to the permanent configuration.

First find where the traffic actually lands - adding the port to the wrong zone does nothing at all:

firewall-cmd --get-active-zones
firewall-cmd --get-default-zone
nmcli -g connection.zone connection show ens4    # blank means: default zone
ip -4 addr show                                        # which interfaces are up

Then make the change permanent and activate it:

firewall-cmd --permanent --zone=public --add-port=8080/tcp
firewall-cmd --reload
firewall-cmd --zone=public --query-port=8080/tcp     # expect: yes
firewall-cmd --zone=public --list-all | grep -E 'ports|interfaces|sources'

If ens4 were assigned to the internal zone, --zone=internal would be required; --add-port to public would be accepted and silently irrelevant. Also confirm httpd is not bound to 127.0.0.1 - ss -ltnp here already shows 0.0.0.0:8080, so the listener is not the problem.

Replace the blanket port with a source-restricted rich rule in the zone that actually owns ens4.

firewall-cmd --permanent --zone=public --remove-port=8080/tcp
firewall-cmd --permanent --zone=public --add-rich-rule=\
  'rule family="ipv4" source address="10.20.0.0/24" port port="8080" protocol="tcp" accept'
firewall-cmd --reload
firewall-cmd --zone=public --list-rich-rules

Reasoning and checks:

• Rich rules are evaluated in order within the zone; removing the blanket port first stops the unrestricted path from surviving alongside the restricted one. Leaving both open is a very common mistake.
• Do the removal and the addition with --permanent in the same pass, then a single --reload. Editing runtime and permanent separately is what lets them drift apart.
• Test from both sides: a client in 10.20.0.0/24 (curl -sI http://10.20.0.5:8080) and one outside it (expect a timeout), and verify from the server with firewall-cmd --zone=public --query-rich-rule='...'.
• If the clients are on a dedicated segment, the cleaner long-term design is to put ens4 in its own zone (nmcli connection modify ens4 connection.zone internal, then firewall-cmd --permanent --zone=internal --add-service=http) so the 'public' zone keeps its default posture. Whichever you choose, record the zone-to-interface mapping - that mapping is what people get wrong during the next reboot.