[clue-tech] forwarded packets not matching any iptables rules?

[Jim Ockers]

Hi Dave,

Thanks for the response and for spending some time thinking about my
problem!

David L. Anselmi wrote:
> 
> Jim Ockers wrote:
> [...]
> > It seems that my problem below is timing or sequence.
> > http://marc.theaimsgroup.com/?l=netfilter&m=112878199509625&w=2
> > 
> > It seems that IF:
> > 1. the interface comes up
> > 2. a UDP packet is seen right away
> > 3. subsequently to (2) the iptables rules are configured
> > 
> > THEN
> > the UDP packets will not get processed by iptables.
> 
> So you can configure iptables first and then bring up eth0 and eth1, 
> right?  The 3. above always happens before 2.  Does that help?

I don't understand your statement.  Here's what I observed happening:
If the iptables rules are configured before the UDP packet is seen,
then that UDP traffic is properly processed by iptables.  If the 
UDP packet is seen before iptables is configured, then the UDP traffic 
is NOT properly processed by iptables.

> Your link says something about some packets getting through anyway but 
> that doesn't make sense to me.

UDP traffic that was seen after iptables was configured is properly
SNATted.  Therefore some UDP packets were being handled properly by 
iptables and thus were getting through the network.

> Perhaps downing both interfaces?  Just a guess.  But if you unload the 
> conntrack module I'd think you'd want the interfaces down anyway to 
> prevent the above sequence from happening when reloading it.

Unfortunately in this embedded system the netfilter code is compiled
into the kernel and cannot be unloaded.

> Can you skip using connection tracking?  That prevents you from using 
> --state rules.

The firewall rules use state extensively.  Good idea though.  In fact
I am not allowed to make any changes to the OS of this device at all.

> You might be able to spoof some RST packets, which is supposed to drop 
> the conntrack timeout to 10 sec.  That's a kludge though and may not 
> actually help.

RST would only affect TCP I think.  UDP, being connectionless, does not
have the notion of RST.

> This says there's a patch in netfilter that will disable conntrack for a 
> src/dst:
> 
> http://lists.sans.org/pipermail/unisog/2005-August/025039.html

Thanks for the idea.  Not a bad idea!  Anyway I did find a workaround
to this problem.  I null routed the offending source IP address on the
firewall.  Then I waited for the conntrack entry to expire.  It turned
out to only be 30 seconds for this particular UDP traffic.  (Downing the
interface would probably also cause the matching traffic to no longer
be seen.)  Once the conntrack entry was gone from the table, then I
removed the null route, and the UDP traffic started being SNATted like
it should.

As a semi-permanent workaround I made my application wait 5 minutes
after power-on before it starts spewing forth the UDP traffic.  That
way the firewall system should have enough time to initialize (assuming
they are both powered on at the same time) before it sees its first
UDP packet.

-- 
Jim Ockers, P.Eng. (ockers at ockers.net)
Contact info: please see http://www.ockers.net/