Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Jan 2006 11:11:30 -0500
From:      Chuck Swiger <cswiger@mac.com>
To:        ikaney@crisiant.com
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Bridging Firewall Machine Questions
Message-ID:  <43D8F4B2.5080102@mac.com>
In-Reply-To: <20060126115051.8840D43D45@mx1.FreeBSD.org>
References:  <20060126115051.8840D43D45@mx1.FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Ian Kaney wrote:
> Hi there. I wonder if somebody could help me with an issue I'm experiencing.

You've asked an interesting question, but there's a lack of data ("vmstat -i",
dmesg, "sysctl net").  You might obtain better results by putting together some
details, maybe as files in a directory being served by HTTP, and sending a link.

> I've put together a bridging firewall using FreeBSD 5.X. The traffic routes
> through fine and presently I'm using IPFW, default policy is set to deny,
> with certain rules/ports allowed to pass through. The three interfaces that
> are being bridged are all gigabit speed. The server is using Intel/Broadcom
> gigabit network cards. The machine that is performing the bridging is a Dual
> Opteron 246 with 2GB memory.
> 
> The issue that I'm finding is that the CPU runs out of power when the links
> are being hit hard. The em0 (fibre) device in particular runs at about 6%
> consistently with normal traffic (~40Mbits/s) being pushed through the
> bridge. This means the machine would run out of CPU power when the link was
> being utilised at around ~650Mbits/s. Is this unavoidable or is this a
> symptom of more CPU power being required?

Are the CPU's busy handling interrupts, in which case enabling interrupt
coalescing (-link0 flag, depending on the NIC) or maybe using device polling
might help?

Have you tried enabling fast-forwarding sysctl?

Or are you busy processing the traffic in your IPFW ruleset, in which case
changing and optimizing your ruleset will likely remove the bottleneck you see.

It's also possible that running the system in single-processor mode might
actually behave better for this kind of workload, because you avoid all the SMP
locking...

> I've also had problems with the bridge running out of dynamic rules. I've
> raised them to silly figures however I'm always wary that if a machine had a
> Trojan or some other form of malware that attempted a DoS attack, the bridge
> would probably fall over after exhausting its dynamic rule count and cause
> more issues. Could this be fixed perhaps by setting the default policy of
> IPFW to accept, or do the dynamic rules get created anyway when bridging?

Dynamic rules shouldn't get created unless your ruleset tells IPFW to make them,
or unless something like natd generates rules dynamicly for active FTP traffic.

It's entirely possible to replace dynamic rules with appropriate static rules
for your most common types of traffic, which may be faster and avoid filling up
the dynamic session table.  For example, instead of doing "pass tcp from me to
any smtp keep-state":

# outside SMTP to pi
add pass tcp from any HIPORTS to PI 25 setup
add pass tcp from PI 25 to any HIPORTS established

# permit SMTP exchange between pi and pong
add pass tcp from PI HIPORTS to PONG 25 setup
add pass tcp from PONG 25 to PI HIPORTS established

add pass tcp from PONG HIPORTS to PI 25 setup
add pass tcp from PI 25 to PONG HIPORTS established

# track SMTP from inside to outside and block SMTP from outside
add pass log logamount 20 tcp from INET HIPORTS to any 25 setup
add pass tcp from INET HIPORTS to any 25 established
add unreach filter-prohib log tcp from any to INET 25

[ Where PI and PONG are macros which expand to the IP addresses of my external
MX relay and the internal reader box, respectively, HIPORTS means 1024-65535,
and INET refers to the internal network. ]

-- 
-Chuck



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D8F4B2.5080102>