pf NAT confusion

[Joel Schander <jschande@cuc.edu>]

Hello,

I am upgrading several OBSD 2.9 firewalls to 3.0 and am making the IP
Filter -> pf conversion. I'm seeing something I didn't expect when
performing NAT for a triple-homed host and hope someone can clue me in on
the elegant fix -- we dont' like the kluge. I didn't see anything in the
archives for the past four months on the subject, but if I missed it, a
link would be great.

Network layout:

Workgroup -------- Firewall ------- Net
                      |
                      |
                      |
                      |
                   Servers


The firewall uses a default deny policy, but all outbound TCP, UDP, and
ICMP is allowed from the workgroup. Traffic going out both the server and
Net-side interfaces have a NAT rule setting their IP to the appropriate IP
used by firewall.  Initially, everything seemed great -- DNS, HTTP, and
SSH traffic got through from the workgroup just fine.  Then I tried AIM --
never connected.  
``pfctl -s state'' returned this (public IP obscured):

TCP  192.168.100.205:1697 -> 24.132.98.223:58824 -> 64.12.26.2:5190
TIME_WAIT:TIME_WAIT

But the other traffic went through just fine...DNS, HTTP, SSH are all
allowed out from the firewall to the Net, but AIM isn't, so let's try
allowing AIM outbound from the firewall's Net-side interface...works
perfectly:

TCP  192.168.100.205:1697 -> 24.132.98.223:58824 -> 64.12.26.2:5190
ESTABLISHED:ESTABLISHED

So, we have a kluge -- open up all TCP, UDP, ICMP traffic outbound from
the Net-side firewall interface -- but we really don't want to do that.
Can I do the following with one quick, keep state rule in pf.conf and one
NAT rule per external interface in nat.conf?
- allow workgroup traffic in on the workgroup interface, passing quick and
keeping state
- NAT the workgroup traffic on the appropriate external interface, using
the interface's public IP
- have that traffic passed through the NATted interfaces as if it weren't

<fingers_crossed>
I really hope It's me doing something wrong and not a case of having to
use the kluge.
</fingers_crossed>

Joel