RL 9.7 strange network issue

Rocky Linux Help & Support
1

RL 9.7 running on Hyper-V, Win2022 host. single 10G Ethernet NIC

This server has a couple of routes to a firewall that services customer VPN tunnels where we NAT the traffic to this Linux server. One customer’s routing works. One does not. Both are set up the exact same way throughout the network. The one that doesn’t work the failure appears to be on this Rocky Linux server. This server also has two IP addresses: 10.0.0.1/24 and 10.0.0.2/24. The NAT is tied to 10.0.0.2 at the firewall. Routing is:
196.100.100.0/24 via 10.0.0.254 dev eth0 proto static src 10.0.0.2 metric 100
200.200.0.0/16 via 10.0.0.254 dev eth0 proto static src 10.0.0.2 metric 100
I’ve also tried swapping the IP addresses so that 10.0.0.2 is primary. Doesn’t help this issue.

The strange part is that anything in that 200.200.0.0/16 subnet works fine. The 196.100.100.0/24 subnet does not work.

When the customer initiates traffic it makes it into the server but the server claims that the remote end is unreachable:
05:52:13.917158 IP 196.100.100.165 > 10.0.0.2: ICMP echo request, id 2, seq 48183, length 40
05:52:13.917247 IP 10.0.0.2 > 196.100.100.165: ICMP 10.0.0.1 protocol 1 port 37154 unreachable, length 68

If I initiate traffic from the server itself the traffic makes it to the customer and back just fine:
05:52:14.434930 IP 196.100.100.165 > 10.0.0.2: ICMP echo reply, id 4, seq 1, length 64
05:52:15.189977 IP 10.0.0.2> 196.100.100.165: ICMP echo request, id 4, seq 2, length 64

Is this a bug? Can this be fixed?

2

Ok this is related to FirewallD. The other client can ping this server without problems. When I disable the firewall here the affected client’s traffic returns successfully.

Edit: We had a broad REJECT for 196.0.0.0/8 and an ACCEPT statement for 196.100.100.0/24. The ACCEPT statement was being ignored and no REJECT logs were being entered. Once we removed the blanket reject this all started working. I would think that the initial packets would have been rejected instead of being accepted then the kernel claiming the address was unreachable. That’s strange to me.

Anyway, this is resolved.

4 Likes