On Wed, Sep 10, 2003 at 10:28:08AM -0400, Jonathan Kay wrote:
> Any ideas on how to fix this?
There are three relevant issues, I think.
First, incoming external connections to your two external addresses
should cause related outgoing replies get routed to the same interface.
If they are not (but sent out through either interface at random), the
upstream ISPs might block them, seeing a 'spoofed' source address.
This is done with rules like
pass in on $ext_if1 reply-to $ext_if1 from any to any keep state
pass in on $ext_if2 reply-to $ext_if2 from any to any keep state
Note the 'keep state'. You should, as a general rule, create state in
every pass rule.
This works together with the redirections to the local servers for
incoming external connections
rdr on { $ext_if1, $ext_if2} proto tcp from any to any port 80 \
-> $webserver
Note that translation comes before filtering, so redirected packets will
have a destination address of $webserver when they get filtered
(matching 'to any' in the pass rules above).
Second, you might want to round-robin outgoing connections across both
uplinks. You have 'pass in on $int_if route-to' rules. That works, but
bypasses the firewall's stack, which can cause problems (as explained
below). I suggest you don't use route-to on the internal interface, but
let all connections get routed to the external interface with the
default route, and use route-to THERE. This isn't too late in the
process, pf can still re-route packets that are about to be sent out
through an interface. Assuming the default route goes through $ext_if1,
that would be
pass out on $ext_if1 route-to { $ext_if1, $ext_if2 } from any \
to any keep state
And third, you're attempting to bounce local connections back into the
local network. This doesn't work without additional care, for a detailed
explanation see
http://www.openbsd.org/faq/pf/rdr.html#reflect
What you might be seeing with the quoted ruleset is that local
connections actually leave through one uplink. Even if you might be able
to actually make that work, I don't think you want to route these
connections through the Internet back to yourself. The other solutions
explained in the FAQ make more sense. Note that if you're using a tcp
proxy on the firewall to bounce the connections back, that will require
incoming connections on the internal interface to actually reach the
firewall's stack. Using route-to on the internal interface will bypass
the stack and break that approach.
I suggest you set up and test each of these three aspects separately,
and then combine the ruleset when each works, and finally debug the
entire ruleset (in case the rules interact). If you need help, feel free
to ask.
Daniel
