netdev - bizarre tcp rst out of nowhere...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CANj2EbebWxd85ddKYuT_2q=ZJRMG+FdD_RwJGNE9jbcs0BuBKA@mail.gmail.com>
Date:	Tue, 8 May 2012 22:04:34 -0400
From:	Simon Chen <simonchennj@...il.com>
To:	netdev@...r.kernel.org
Subject: bizarre tcp rst out of nowhere...

I am running a ubuntu 11.04 server, with kernel flavor 2.6.38-13-server.

The server is running nova-network, the openstack network controller.
Essentially, it is doing a static NATting function. When a packet
comes from a VM, it SNAT the VM's private src IP to a public floating
IP and send the packet out. When a packet is sent to the floating IP,
it DNAT the packet to the VM's private IP in reverse.

So, the server in question should be a strictly pass-through device,
while doing address translation. It doesn't have any additional
filtering rules.

I have a remote client trying to "curl https://floater_ip". The
bizarre thing is that this sometimes works, sometimes doesn't. When it
works, the packets go through my NAT server as normal. When it doesn't
work, it seems that my NAT server decides to send back a tcp-rst
immediately after the tcp-syn is received - it is supposed to pass it
on, not process it locally...

Any idea why this happens?

I've been watching the server closely, the floater IP is always on the
public nic, the iptables rules are always there, the interface is
always up, the backend VM is always reachable...

-Simon
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html