I have a suspicion that route-to is changing sequence numbers on TCP packets.

My pf-based router is set up so that packets travelling between
internal hosts and the internet get routed through a separate IPS box:
imagine the IPS as basically a plugin to the router, and packets get
temporarily diverted through it on their way out.

Say a packet from an internal host enters $int_if, and matches a rule
which sets it to route-to ($ips_if1, $ips_ip1). When I tcpdump on
$int_if and $ips_if1, I can see the packet's SN is different on the
two interfaces.

Now, with my setup, the IPS sends the packet back to the router (on
$ips_if2) to be sent out to the internet. If the packet matches a
block rule on $ext_if, the router sends a RST packet back to the
internet host directly, without sending it back via the IPS. Because
the SN has changed, this means the SN on the RST doesn't match, and
the host ignores the RST.

As I understand it, there's no way to apply pf rules to pf-generated
packets such as RSTs, so there's no way to force the RST back through
the IPS.

I don't have any "scrub" or "modulate state" rules, and packets which
don't have a route-to applied keep their SNs unchanged.

Is there any way at all to stop route-to changing the TCP sequence number?

(Or if I'm mistaken in my diagnosis and it's not route-to's fault, any
ideas what might be causing the SN to change? State policy is
if-bound, and $ips_if1 doesn't keep state on any packets.)

This is the pf included on FreeBSD 7.2.

Thanks.

Oliver.