TCP RSTs seen when routing is expected.
supadupa at gmail.com
Sun May 17 12:30:28 MDT 2009
See inline below. Also, "us" is usually the system/server/device here
in question. "it/there/them" as being away from us is the final
On Sun, May 17, 2009 at 10:16 AM, Kenneth Burgener
<kenneth at mail1.ttak.org> wrote:
> On 5/17/2009 3:40 AM, Scott Edwards wrote:
>> I'm expecting this box to forward traffic like a router, but it's not
>> playing nice. It might be because I'm up at 3:30am trying to figure
>> this out. hah :) the 192.0.0.2 address is simply for "example.com"
>> style usage.
>> forwarding was enabled by echo 1 > /proc/sys/net/ipv4/ip_forward
>> iptables-save shows all chains are ACCEPT. There is one rule in the
>> nat table, FOWARD chain, as ACCEPT, however there are no packets/bytes
>> accounted for.
> A couple of suggestions...
> 1. Does the forwarding work with a completely flushed iptables? Try the
> iptables -P INPUT ACCEPT
> iptables -P OUTPUT ACCEPT
> iptables -P FORWARD ACCEPT
> iptables -F
> iptables -X
> for table in filter nat mangle; do
> iptables -t $table -F
> iptables -t $table -X
> iptables -t $table -Z
I'll have to try this later (on a maintenance window). I'm not sure
there is any real effect, as the complete iptables rule set was
provided by iptables-save. The only thing I've altered is ip
addresses for accounting. Shortly thereafter, tcpdump made it evident
no forwarding was taking place.
> 2. Does your destination have a firewall enabled that could be blocking the
Good question. I'm still confused as to why the TCP RST's are being
generated by the mac address that's suppose to be forwarding it (us).
This address is not assigned to this server, but it's acting like it
is here with a closed port.
This is not responding like I would expect for transit traffic. This
behavior is more like host (we own the destination) traffic.
I think I will take a close look at routing information running on the
server, to see if the route for the prefix is just as I expect.
> 3. Is your internal interface enabled? Does your internal interface have an
> address that is in the "network" range that you are forwarding to?
The destination is reachable in the same subnet this interface is
configured for. This server has one address assigned in the range,
and the destination is different.
> 4. Does your internal network have "public" or "private" IP addresses? If
> they are private do you have the NAT masquerading configured for the right
All public routable addresses. (now if we will just route it ...)
Thanks for the responses Kenneth, I'll have to double check the
routing information to see if anything fishy comes up.
More information about the PLUG