Re: iptables not responding to packets destined for subinterface

[Pete Toscano <pete-netfilter@verisignlabs.com>]

Support Team wrote:
> My public interface has serveral IP address aliases.  Only the primary IP
> address responds to traffic (ip, imcp, et al).  I inserted a log statement
> at the top of each table and found that the packets destined for the virtual
> addresses never made it to any table.  However, according to tcpdump, I
> confirmed that the packets did get picked up by the kernel on the secondary
> address.  I guess they are just not passed to iptables.  Obviously, the
> packet was never replied to (icmp) or acknowledged (ip) by the process.
> 
> How can I get iptables to respond to the packets on the secondary
> interfaces?  Or, how can I get the kernel to pass the packets to iptables?
> 
> I understand that when the packet hits the chain, all I have to do is create
> a rule with the primary interface and use the IP address to distinguish the
> packets of different virtual addresses.

Patrick,

I don't have time to read the volume of details of your message, but the 
summary sounds a lot like a problem I was having.  Maybe this will help you.

I was upgrading a bunch of boxes.  I'd take a spare box, configure it, 
then swap it in in place of the old box.  I was seeing some real 
strangeness.  In tcpdump, I could see the packets, but they weren't 
hitting the iptables chains (verified with LOG statements at the top of 
every chain in every table).

It turns out to have been an ARP cache issue.  The router I was attached 
to still had the MAC address of the old machine's Ethernet interface in 
its cache.  I could see the packets in tcpdump because it was putting 
the interface in promiscuous mode and filtering on the "problem" IP 
address assigned to one of my subinterfaces.  It wasn't until I finally 
looked at the dest MAC address in the packets I was seeing in tcpdump 
(but not in iptables) and compared it to my actual MAC address that I 
figured out this problem.  A simple ARP cache flush on the router 
cleared up the problem.  (Or, if you're patient, just waiting for the 
relevant entries to timeout would work too.)

Hopefully, this helps you with your problem (or maybe it'll help others).

pete