OpenBSD: extraño caso de fallo de nat con PF

Bueno me encuentro en una situación a la que la he denomidado como
curiosamente extraordinaria. Tengo una box OpenBSD 4.7 con kernel
stable "GENERIC" y sistema base actualizado via cvsup:

OpenBSD 4.7-stable (GENERIC) #0: Mon Oct 25 07:25:13 COT 2010
    root@garagbsd.my.domain:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Celeron(R) CPU 2.00GHz ("GenuineIntel" 686-class) 2 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF
LUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID,xTPR
real mem  = 527986688 (503MB)
avail mem = 502870016 (479MB)

imagenes:
http://www.flickr.com/photos/m0n0/4982033658/
http://www.flickr.com/photos/m0n0/4981450139/

Como lo observan es una box con hardware antiguo y limitado, y que el
sistema operativo "lo pone a andar" sin contratiempos y con
personalidad xD. Lo tengo andando en un cafe internet de mi padre como
cortafuegos,proxy y control de contenido, los dos ultimos operan sin
novedad. Ahora mi inquietud es que hay una regla especial dentro de
pf.conf que me está "mamando gallo" en ciertas condiciones.

Topología:
La conexión a internet es via ADSL de Telefónica, un modem ZTE ZXV10
W300 (feo con aspecto desechable!). los puertos LAN se asignan bajo
DHCP ( 32 direcciones a partir de la 192.168.1.2/24). Sigue entonces
la caja OpenBSD con interfaz rl0 (LAN con asignación manual
192.168.3.1/24) y rl1 (WAN asignada via DHCP desde el ZTE)
Efectivamente mi interfaz rl1 via dhcp recibe la dirección y con la
config defacto que viene con PF hace el NAT sin contratiempos desde la
misma caja. Pero si voy a una estación por debajo de la LAN de la caja
no me lo permite!. Este es la config pf.conf minimo qu usé para esto:

/etc/pf.conf
int_if="rl0"
ext_if="rl1"
localnet=$int_if:network
torrent="{ 6881:6999 }"
# scrub incoming packets
match in all scrub (no-df)


# Configuring NAT
# NOTE: This information is for OpenBSD 4.7. NAT configuration was
significantly different in earlier versions.
pass out on $ext_if from $localnet to any nat-to ($ext_if)


# Default deny
block in all
block out all


table const { self }
set skip on lo
antispoof log for $ext_if
block in quick from urpf-failed


# pass all traffic to and from the local network.
# these rules will create state entries due to the default
# "keep state" option which will automatically be applied.


pass in  on $int_if from $localnet
pass out on $int_if to $localnet


pass out on $ext_if proto { tcp, udp, icmp } all modulate state


# pass in log on $ext_if inet proto icmp to $ext_if
pass in log on $ext_if inet proto tcp to ! port { ssh,http
} synproxy state



Resumen hasta ahora: "Pienso que inexplicablemente algo ocurre entre
los "NAT's" del PF y del ZTE que no se entienden pa' nada!"

Debido a ello y revisando el FAQ oficial de openbsd con respecto al
tratamiento de NAT hago un cambio en la linea
pass out on $ext_if from $localnet to any nat-to ($ext_if)
comentandola y ajustandola por
match out on $ext_if from $localnet to any nat-to ($ext_if)

Yupi!, funciona el NAT con la estación debajo de la LAN :D pero pero
pero.. el tratamiento del pf.conf es insuficiente ya que las reglas de
block return out quick on $ext_if subsiguientes no hacen absolutamente
nada, no filtran no bloquean ya que ese cambio de forma para NAT no es
controlable con esos guiones.

==============================================
Topología: Segundo Intento!
No me doy por vencido y agrego entonces un router/AP Linksys por
debajo del ZTE y por encima de la caja openbsd.

ZTE-LAN: DHCP (IP:192-168.1.1) -> Linkys WRT54-RangeBooster WAN
(192.168.1.2), LAN DHCP (IP:192.168.2.1) -> openbsd wan
(IP:192.168.2.107) , LAN DHCP (IP:192.168.3.1)

En firmware propietario del LinkSys agrego una ruta estatica para
resolver la red 192.168.3.0 cuyo gateway es la interfaz wan de la caja
obsd (192.168.2.107). Entonces efectivamente el tratamiento de nat en
pf oficial usando

pass out on $ext_if from $localnet to any nat-to ($ext_if)

en el /etc/pf.conf Funciona permitiendome restringir entonces todo lo
demas y efectivamente poder controlar todo con mi pf

Como la ven, muy complicada la cosa ?.-..
finalmente, a que se deberá eso señores!, comentarios?