no outside network access after upgrade to 8.1

[hfrenzel]

Hello,
after upgrading to 8.1.1911 I can no longer access (ssh, ping, http) my machine, except from hosts on the same subdomain (same first 3 digits of IP address).
Disabling the firewall didn't help. sshd is running.

It's more or less the same as described in
viewtopic.php?f=56&t=73150

but I get
sshd -T | grep listen
listenaddress [::]:22
listenaddress 0.0.0.0:22
permitlisten any

Any ideas? I appreciate the help!

[TrevorH]

Sounds more like a routing problem. What's the output from

ip ad sh
ip ro sh

[hfrenzel]

ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp6s0f0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:25:90:85:4c:0c brd ff:ff:ff:ff:ff:ff
3: enp6s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:25:90:85:4c:0d brd ff:ff:ff:ff:ff:ff
4: enp6s0f2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:25:90:85:4c:0e brd ff:ff:ff:ff:ff:ff
inet 10.141.167.244/16 brd 10.141.255.255 scope global noprefixroute enp6s0f2
valid_lft forever preferred_lft forever
inet6 fe80::e5d7:a53a:e8d:d1e1/64 scope link noprefixroute
valid_lft forever preferred_lft forever
5: enp6s0f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:25:90:85:4c:0f brd ff:ff:ff:ff:ff:ff
inet x.x.x.62/24 brd x.x.x.255 scope global noprefixroute enp6s0f3
valid_lft forever preferred_lft forever
inet6 fe80::fe40:8735:c6a6:caa8/64 scope link noprefixroute
valid_lft forever preferred_lft forever
6: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:23:29:be brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
7: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:23:29:be brd ff:ff:ff:ff:ff:ff

ip ro sh
default via 10.141.255.254 dev enp6s0f2 proto static metric 102
default via x.x.x.100 dev enp6s0f3 proto static metric 103
10.141.0.0/16 dev enp6s0f2 proto kernel scope link src 10.141.167.244 metric 102
x.x.x.0/24 dev enp6s0f3 proto kernel scope link src x.x.x.62 metric 103
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown

(I replaced the first 3 numbers of the external IP addresses with x.)

[hunter86_bg]

Nice you have 2 gateways , but which one is the true one ?
My guess is that you need to remove

default via 10.141.255.254 dev enp6s0f2 proto static metric 102

[jlehtone]

Presuming both interfaces do get config from DHCP, I would set ipv4.never-default true on the LAN connection.
There is no point to route to WAN via LAN, if you already are directly hooked to the WAN.

[hfrenzel]

I have an internal network (10.141.x.x) for some other servers in the same room and an external one. The first one works fine, the latter only for outbound traffic to all destinations and inbound traffic from its own subdomain, but not any other places.
Both IPs are static.

[TrevorH]

Yes but you have set GATEWAY= on both and only one can win and it's a race as to which one it will be. Remove the GATEWAY from the interface that you do not want to be the default and possibly add static routes via the other interface for those subnets that are behind it (not required if everything behind it is in the same subnet).

[jlehtone]

The first one works fine

However, it is the error in its config that ruins your day.

As is, the default via 10.141.255.254 src 10.141.167.244 is the default route.

When you connect to centos.org, you send to 10.141.255.254, which probably sends to x.x.x.100 and so forth. The replies return via x.x.x.100 to 10.141.255.254 and then to 10.141.167.244, as expected.

When google.com connects to x.x.x.62, you will send a reply to 10.141.255.254, which forwards (via x.x.x.100) to google. Google does not expect any answer from x.x.x.y and it will never get answer from x.x.x.62.


Unset the ipv4.gateway on the LAN connection.

[hfrenzel]

That was indeed the problem.

Thanks so much for your help!