I have kind of a strange problem. After rebooting a server a few days ago, it doesn't route its packages correctly. It basically doesn't answer (pings for example) if these packages come from specific networks.
It's a virtual machine (Qemu, KVM, Debian 10). On the same host there is another virtual machine, nearly identical to the problematic one, which works just fine.
They are using the same bridges to communicate, both are using virtio-drivers for their network interfaces, both have empty iptables and their routing tables are the same.
The affected server has the ip 172.16.0.30. The functioning server has the 172.16.0.93.
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.0.1 0.0.0.0 UG 0 0 0 ens10
172.16.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens10
172.16.2.0 0.0.0.0 255.255.255.0 U 0 0 0 ens3
-------------------------------------------
root@server:~# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
-------------------------------------------
root@server:~# ip addr show dev ens10
4: ens10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:87:2a:5f brd ff:ff:ff:ff:ff:ff
inet 172.16.0.30/24 brd 172.16.0.255 scope global ens10
valid_lft forever preferred_lft forever
If I ping the client 172.16.34.123 for example, ping on my server will tell me, it didn't receive any packages. But tcpdump on the gateway and on the server itself reveals, that the server got packages but somehow doesn't react to them.
root@opsi:~# ping 172.16.34.123
PING 172.16.34.123 (172.16.34.123) 56(84) bytes of data.
--- 172.16.34.123 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 70ms
-------------------------------------------
root@server:~# tcpdump -n -i ens10 host 172.16.34.123
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens10, link-type EN10MB (Ethernet), capture size 262144 bytes
09:37:56.850996 IP 172.16.0.30 > 172.16.34.123: ICMP echo request, id 1293, seq 1, length 64
09:37:56.852292 IP 172.16.34.123 > 172.16.0.30: ICMP echo reply, id 1293, seq 1, length 64
09:37:57.869612 IP 172.16.0.30 > 172.16.34.123: ICMP echo request, id 1293, seq 2, length 64
09:37:57.870655 IP 172.16.34.123 > 172.16.0.30: ICMP echo reply, id 1293, seq 2, length 64
09:37:58.893600 IP 172.16.0.30 > 172.16.34.123: ICMP echo request, id 1293, seq 3, length 64
09:37:58.894489 IP 172.16.34.123 > 172.16.0.30: ICMP echo reply, id 1293, seq 3, length 64
Like I said, the other machine, which connects to the same bridge, doesn't have this problem. If I ping the server from another machine, the server will get the package, but doesn't send a reply. Up until a few days ago, this server worked correctly. I tried changing network devices, network drivers and changing the configuration between dhcp and static settings.
Pinging another network (10.8.0.0) works just fine.
root@server:~# ping 10.8.0.39
PING 10.8.0.39 (10.8.0.39) 56(84) bytes of data.
64 bytes from 10.8.0.39: icmp_seq=1 ttl=63 time=22.8 ms
64 bytes from 10.8.0.39: icmp_seq=2 ttl=63 time=25.10 ms
64 bytes from 10.8.0.39: icmp_seq=3 ttl=63 time=23.9 ms
^C
--- 10.8.0.39 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 22.794/24.212/25.975/1.321 ms
--------------------------------------------
root@server:~# tcpdump -n -i ens10 -qtln icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens10, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 172.16.0.30 > 10.8.0.39: ICMP echo request, id 3556, seq 1, length 64
IP 10.8.0.39 > 172.16.0.30: ICMP echo reply, id 3556, seq 1, length 64
IP 172.16.0.30 > 10.8.0.39: ICMP echo request, id 3556, seq 2, length 64
IP 10.8.0.39 > 172.16.0.30: ICMP echo reply, id 3556, seq 2, length 64
IP 172.16.0.30 > 10.8.0.39: ICMP echo request, id 3556, seq 3, length 64
IP 10.8.0.39 > 172.16.0.30: ICMP echo reply, id 3556, seq 3, length 64
Any idea what the reason could be?
