>From owner-m...@openbsd.org
Received: from shear.ucar.edu (lists.openbsd.org [192.43.244.163])
by lib.oat.com (8.14.3/8.14.3) with ESMTP id o2PHfPNN023169
for <g...@oat.com>; Thu, 25 Mar 2010 13:41:28 -0400 (EDT)
Received: from openbsd.org (localhost.ucar.edu [127.0.0.1])
by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id o2PHdSXJ009239;
Thu, 25 Mar 2010 11:39:28 -0600 (MDT)
Received: from pr.neotoma.org (raleigh.neotoma.org [24.106.182.151])
by shear.ucar.edu (8.14.3/8.14.3) with ESMTP id o2PHarnF026642
for <misc@openbsd.org>; Thu, 25 Mar 2010 11:36:54 -0600 (MDT)
Received: by pr.neotoma.org (Postfix, from userid 1002) id 66CF52EC3B; Thu, 25
Mar 2010 13:36:53 -0400 (EDT)
Date: Thu, 25 Mar 2010 13:36:53 -0400
To: Geoff <g...@oat.com>
Cc: misc@openbsd.org
Subject: Re: pf vs. bridge vs. spamd
On Wed, Mar 24, 2010 at 09:08:48PM -0400, Geoff wrote:
> I'm trying to set up spamd on my firewall system.
>
> The configuration is tricky because my upstream provider
> (Verizon) only gives me 5 IPs, all on the same subnet.
>
> The firewall system is acting as a bridge and as a router.
<SNEEP>
On Thu Mar 25 at 13:41:29 2010, Chris Dukes wrote:
>I think you're taking the wrong approach here by including a bridge.
>Configure the interface with the default route to have all 5 IP addresses.
>Configure the hosts to be protected by the firewall, but reachable by
>the public internet to be on one or more subnets within the RFC 1918 space.
>Use rdr rules (or the newer equivalent) for the SPECIFIC access required
>by from the public internet. Use nat rules for the specific access
>they need to the public internet.
>*IF* you do that you can use relayd or some of the fancier rdr rules
>to load balance across multiple backend hosts.
>You can also use one IP address to service multiple services that
>are actually provided by multiple backend boxes if the load demands
>such separation.
Your solution is quite nice, except for one problem:
The hosts inside the firewall need to know
their external addresses. That can't change.
PF is an IP facility. Unfortunately, in order for it to
work correctly when applied to a bridge, once a packet has
been redirected it needs to get a correct link-level address.
Right now, packets are assigned routes (implying link level
addresses) at ingress. Routes need to be reassigned if packet
destinations change during bridging.
That's the core problem.
I've had a lot of problems with IPSEC, etc, due to the
ad-hoc interactions of IP level functions with link-level
functions. I've thought of a scheme to fix this but obviously
I don't want to go through development if there's a solution
already.
Geoff
