Re: intermittent and unreliable behaviour with iptables scripts

[Joel Newkirk <netfilter@newkirk.us>]

On Monday 11 November 2002 12:25 pm, Doug Watson wrote:
> Fellow list users,
>
> I have been attempting to set up a new firewall for my company with the
> two goals of 1. implementing statefull packet filtering and 2.
> creating a DMZ for servers that need to be accessed by the
> outside world, such as HTTP, SMTP, DNS and FTP.
>
> There seems to be a lot to describe here so please stick with me.

OK, but I'm going to snip liberally... :^)

> When browsing the web, web pages that normally would load very quickly seem
> to hang for an inconsistent amount of time, anywhere between 1 second to 30

> I will note that when the firewall is in the state that no web pages will
> load, pings to its LAN interface which usually return in about 1ms will
> time timeout, but I have not been able to link this to any specific network

So the problem is probably occurring in PREROUTING or routing, since it hits 
both forward and input packets. Try inserting in nat prerouting and filter 
forward and input:

$IPTABLES -t filter -I FORWARD 1 -i $LAN_IFACE -p ICMP -j LOG --log-level 
debug --log-prefix "IPT:SlowPingFront: "
$IPTABLES -t filter -I FORWARD 1 -o $LAN_IFACE -p ICMP -j LOG --log-level 
debug --log-prefix "IPT:SlowPingBack: "

Reproduce your problem and slow ping (-i 10 perhaps, -w 10000 from windows) 
from the lan to the firewall and beyond, and see what picture the log paints.  
If the ping is just dying somewhere you can (hopefully) see it's trail.  If 
it's really slow (several seconds) you've hopefully narrowed it down to WHERE 
it's slowing.

Check /proc/net/ip_conntrack, general memory issues, and top.

> Also overall speed of our connection seems to be noticeably slower when
> running through this firewall. One example be it a good one or not is
> when running the high speed bandwidth test at http://www.bandwidthplace.com
> through the current firewall the average speed returned is between 1.0 and

> same test through the new iptables based firewall the average speed
> returned usually in the range of 600 to 800 Kbps.

This is quite possibly the same thing as above, just in a less intrusive part 
of the cycle...  However, I had a few suggestions on your forward and 
bad_tcp_packets chains.

- disclaimer -
below is largely feng shui firewalling.  After a dozen readings of your 
firewall (cigarette breaks outside :^) it just didn't 'feel' right, and the 
changes below 'improve the flow' and 'feel right' often without any firm 
justification.  (along with some clarity and simplicity)  However, you DID 
ask for thoughts in general...
- /disclaimer -

Move the spoof tests from bad_tcp_packets to their own chain, or just move the 
state tests directly to the start of forward and input.  (Do you need them 
for output?  You certainly don't need to test for -i $INET_IFACE in 
output...)  Call the spoof tests next, to catch both $LAN and $DMZ bound 
spoofs.

You currently accept EST/REL from $INET back to $DMZ, then have tests for new 
connections on that route, then blanket EST/REL.  Make your unrestricted 
EST/REL rule next instead, followed by your $LAN accept rule, unless you want 
to block otherwise valid EST/REL involving the DMZ, in which case the 
following two rules have to come before the EST/REL.  -i $LAN -o $DMZ ACCEPT 
is redundant, picked up in the -i $LAN ACCEPT that follows in your current 
sequence, and EST/REL -i $INET -o $DMZ or -o $LAN are subsumed in the blanket 
accept.

Follow this up with a jump for -o $DMZ_IFACE -j DMZin, then  -o $DMZ_IFACE -j 
DMZout.  and move all appropriate rules to those chains.  Now you can treat 
DMZin almost like INPUT for the DMZ, and DMZout like OUTPUT, and keep all DMZ 
rules separate from lan<->inet.  You can easily insert/remove a blanket 
accept/reject/drop/return target at the head, or add 'policy' at the end.  
All that these rules need to test now is protocol related, the other 3 
matches for each -i $INET rule are eliminated.  (unless you later use -d or 
-p to filter various DMZ forwards differently)  Also, if you have this before 
your EST/REL then the DMZ chains should each get their own EST/REL at their 
end, before any 'policy' rule.

Finish out with your log rule.  Don't forget to change INPUT (and OUTPUT) to 
reflect the removal of bad_tcp_packets, if you integrated the state rules.

Thus ends today's session of Feng Shui Firewalling.  :^)  The resulting script 
is simpler and more easily modified than currently, and the process is 
simpler than the instructions.  As far as I see, it achieves the same 
filtering and forwarding as your current script with potentially far less 
rule tests per packet, but if I've missed something somebody please correct 
me.

j