Why leak local IP addresses to external interface through NAT in Linux with KVM?

Question

linux

I can’t overcome the problem - local IP addresses leak through NAT to the external interface, for which from time to time I catch an external IP address ban from the provider (Hetzner) I use Debian + Proxmox and KVM virtualization
Packets with the FIN flag and RST tcpdump log from the provider leak.
tcpdump sent by ISP:

09:42:16.976198 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2312 > 192.198.93.78.80: Flags [F.], seq 
3579355710, ack 2348566885, win 65101, length 0
09:42:17.076330 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2271 > 65.75.156.119.80: Flags [F.], seq 
3329167346, ack 2138564996, win 65408, length 0
09:42:17.177311 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2096 > 149.47.143.131.80: Flags [F.], seq 
833600034, ack 1463451994, win 65205, length 0
09:42:17.378092 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2160 > 193.234.222.240.80: Flags [F.], seq 
380954537, ack 1918089133, win 65530, length 0
09:42:17.478724 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2522 > 199.231.188.243.80: Flags [F.], seq 
2524482819, ack 2992113059, win 64726, length 0
09:42:17.482664 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.2376 > 118.139.177.199.80: Flags [F.], seq 
3912490494, ack 3173571000, win 65464, length 0
09:42:17.512824 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.3493 > 192.126.137.25.8800: Flags [R], seq 
714854646, win 0, length 0
09:42:17.512847 a1:b2:c3:d4:e5:f6 > aa:bb:cc:dd:ee:ff, ethertype IPv4 
(0x0800), length 60: 10.0.0.7.3493 > 192.126.137.25.8800: Flags [R], seq 
714854646, win 0, length 0

in sysctl.conf only
net.ipv4.ip_forward=1
Network setting is included:

# Loopback device:
auto lo
iface lo inet loopback


# device: eth0
auto  eth0
iface eth0 inet static
  address   xx.xx.xx.42
  broadcast xx.xx.xx.63
  netmask   255.255.255.224
  gateway   xx.xx.xx.33
  # default route to access subnet
  up route add -net xx.xx.xx.32 netmask 255.255.255.224 gw xx.xx.xx.33 eth0


auto vmbr0
iface vmbr0 inet static
    address  10.0.0.254
    netmask  255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0

Nat's rule:

iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -j SNAT --to-source xx.xx.xx.42

I also tried macarading - the problem did not go away :(
Software versions:

cat /etc/debian_version
7.2

uname -a
Linux 1.server.com 2.6.32-25-pve #1 SMP Tue Oct 1 09:17:16 CEST 2013 x86_64 GNU/Linux

pveversion -v
proxmox-ve-2.6.32: 3.1-113 (running kernel: 2.6.32-25-pve)
pve-manager: 3.1-17 (running version: 3.1-17/eb90521d)
pve-kernel-2.6.32-25-pve: 2.6.32-113
lvm2: 2.02.98-pve4
clvm: 2.02.98-pve4
corosync-pve: 1.4.5-1
openais-pve: 1.1.4-3
libqb0: 0.11.1-2
redhat-cluster-pve: 3.2.0-2
resource-agents-pve: 3.9.2-4
fence-agents-pve: 4.0.0-2
pve-cluster: 3.0-7
qemu-server: 3.1-5
pve-firmware: 1.0-23
libpve-common-perl: 3.0-6
libpve-access-control: 3.0-6
libpve-storage-perl: 3.0-13
pve-libspice-server1: 0.12.4-2
vncterm: 1.1-4
vzctl: 4.0-1pve3
vzprocps: 2.0.11-2
vzquota: 3.1-2
pve-qemu-kvm: 1.4-17
ksm-control-daemon: 1.1-1
glusterfs-client: 3.4.0-2

Answer 1

On the rights of poking a finger into the sky, tried to natit all the traffic?

/sbin/iptables -t nat -a POSTROUTING –o eth0 -j MASQUERADE

Answer 2

I tried it, it doesn't help
packets keep pouring
in. I noticed that packets are pouring in when their virtual machines generate quite a lot, from 1k through nat
some kind of queue may overflow and / or the piece of iron does not have time to process them?

Answer 3

You use the vmbr0 bridge, anything can go through it to the external network.
show brctl show.
If it turns out that both eth0 and virtual machine interfaces are connected to the bridge, then ebtables should be used to block.
It still does not hurt to properly configure the gateway on 10.0.0.7 so that it does not try to contact external nodes directly.

Answer 4

You use the vmbr0 bridge, anything can go through it to the external network.
show brctl show.

there is also an example of a config
if eth0 was included in the bridge, I could still suspect it, and so they are physically isolated
on the virtual machine the following settings

ip: 10.0.0.7
mask 255.255.255.0
gw: 10.0.0.254
ns: 10.0.0.254

Can you explain what you mean by "normal"?

Answer 5

Again, at the level of a finger in the sky -
iptables -t nat -L POSTROUTING
does not seem to surprise anything?
iptables -t raw -I OUTPUT -o eth0 -s 10.0.0.0/8 -j DROP