[Shorewall-users] Firewall for IIS boxen

Barbara A. Severance babbs@digihorse.com
Wed, 15 May 2002 01:46:38 -0700

I've set up quite a few firewalls which Shorewall, and never run into this
situation.  The setup is:

Linux server as $FW 
RedHat 7.2 (patched)
Custom Kernel 2.4.18 (made to be a router/firewall)
IPTables 1.2.6a  from source, additional relevant patches from patch-o-matic,
compiled directly into kernel, and not as modules.... 
Shorewall 1.2.13

2 NICs  eth0 and eth1.  eth0 is multihomed, and is the primary external
interface. eth1 also has an external IP from the same block (.192 SN) and is to
act as the GW to the IIS server. The box to be firewalled is an IIS server with
an external IP. (2 actually)  It also has an internal NIC to talk to the SQL

Shorewall is configured with 2 zones, net and GW.  Net is eth0, GW is eth1   I
have proxy arp for the 2 IPs on the IIS box, and they are properly added to the
routing table. The IIS box external has its gateway set as the eth1 interface. 
NAT etc. are all enabled. The IIS Web server is running at a high port to
"protect" it from the standard port 80 attacks.  I have sucessfully gotten the
following to work>  ACCEPT net  GW:xxx.xxx.xxx.xxx.:9160 tcp 80 -
xxx.xxx.xxx.xxx   where the server IP is the IIS web server/port and the address
= an IP bound to the firewall itself, and currently running an Apache Virtual
with a frameset to "hide" the IIS box. This address is what DNS gives for the

Everything "works" for about 3 minutes, and then it gets slower, and slower,
until you get "Connection refused messages".   tcpdump and the IPtables logs
offer no help, as they show connections going through, being accepted and
answered....   If I do a shorewall clear, and then stop and start, the
connection is golden again, and then quickly degrades.  I've never seen this
problem before.... and I'm totally stumped. 

We are doing this to do as much port/access blocking on this MS box as possible.
Using the Apache redirect would work great, but there have been a few times when
apache has burped, and TPTB don't want it in front of this site any longer. 
They also want it to appear on port 80, as we've started having problems with
people not being able to access it at the higher port :) Security ya know....