Hi, 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. PS please cc me into replies, since the list server rejects my "subscribe" requests as spam :(
