Does anybody know any other ways to achieve this level of control,
  without buying another computer?

Sure - you could modify ipf so that it had two incoming tables, and
call it with the second table after IPsec processing.  This might not
be that hard.  IMHO just moving the firewall to after IPsec is not a
reasonable general solution, as many people want the policy of 'drop
port FOO, unless it came in IPsec'.

In your case you could move, or duplicate, the call to ipf input
checking, to after IPsec processing.  I suspect this would be pretty
easy, and browsing cvs logs might show that it used to be that way.
(Perhaps a second call to ipf should be the norm after tunnel mode
decapsulation, with some sort of flag that can be tested in ipf rules
to check for this case.)

You could perhaps kludge something up with a gif, forwarding packets
over a gif that then goes over IPsec (and more importantly the
reverse).  This should let ipf run again on gif input.

IPsec in theory (see RFC2401) allows fine-grained control of incoming
packets in the SPD.  You may be able to cons up SPD entries that act
as firewall by having discard policies matching some ports.  I am not
optimistic that this will work correctly or reliably with the current
code, but I haven't tried it.

You could filter at the main office end, if you control/trust that
computer, as the packets get to the office security gateway before
they enter the tunnel.

        Greg Troxel <gdt@ir.bbn.com>