Perhaps using 'dup-to' could be a solution:
(using original setup: rl0 -> switch, rl1 & rl2 bridges)

the firewall has default route pointing to rl1 and
has a dup-to rule:

pass in quick on rl0 dup-to rl2 from 192.168.4.3 to any port ...

this way reply packets will hit both outgoing interfaces and
one with the original redirect will fix it.

there must be a block rule on both outgoing interfaces to filter out
packets that are not fixed by address translation:

block out on {rl1, rl2} from 192.168.4.3 to any port ...

This may fix the need for a second firewall at the expense of
more (internal) traffic/utilization.

I do not have a setup to test such a configuration but it may just work

Can

On Wed, Oct 02, 2002 at 10:35:08AM +0200, Cedric Berger wrote:
> This is a routing problem, and a PF limitation.
> Here is how you can do it, but you would need 2 firewalls for that.
>
[snip]
>
> Ok, what is really important on this settings it that each
> of the firewall has its default route different, pointing
> upstream on the internet.
>
> Now here comes the trick: you need to put the following
> rules on each firewall:
>
> FW1:
>
[snip]
>
>
> The "trick" here is the NAT lines. this is NOT for outgoing traffic. this
> NAT
> line is for incoming traffic. it will create a second state on the firewall,
> first state is the redirect, and second state will change the *source*
> address
> of incoming packets to be the internal IP of the firewall. If you do that,
> the
> servers will believe that all connections comes from the internal addresss
> of
> one of the firewall, and will be able to route it back to the correct
> firewall.
> This will create true symetrical routing (that was the problem in your first
> setting).
>
> I've tested that, it works perfectly with 3.1. There is only one problem,
> you loose on the server the ability to know the real source address of
> your connections. that might or might not be a problem for you. usually,
> this info is just used for logging, and logging can be done on the firewall
> as well.
>
> Now of course, that would be great to have an option in PF to remember from
> which interface a state originate, and having PF send it back to the same
> IF!
>
> Hope that helps,
> Cedric

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]