IPFW2 verrevpath issue (IPv4 TCP, fresh kernel)

Hi,

I seem to have difficulties with verrevpath in IPFW2 (current kernel,
cvsupped a few hours ago) which APPEARS to not match - or am I too
whatever to configure ipfw2 properly?

Excerpt from "ipfw show":

| 00100    38   3216 allow ip from any to any via lo0
| 00200     0      0 deny ip from any to 127.0.0.0/8
| 00300     0      0 deny ip from 127.0.0.0/8 to any
> 00400    39  12941 deny log ip from any to any not verrevpath in
| 00500     0      0 deny ip from 192.168.0.0/24 to any in via tun0
| ...

Now, when I try to connect from my machine to a remote one with
"ssh user_at_1.2.3.4" I'm getting loads of

| kernel: ipfw: 400 Deny TCP 1.2.3.4:22 217.225.230.222:49228 in via tun0
| kernel: ipfw: 400 Deny TCP 1.2.3.4:22 217.225.230.222:49228 in via tun0

in syslog and the counter of the 00400 rule increases, and I don't get a
connection.  Leaving out the 00400 rule makes my outbound TCP
connections work.  (Apparently the 00400 rule swallows the SYN|ACK
packets.)

217.225.230.222 is my IP and 1.2.3.4 is the remote IP. tun0 is a PPPoE
interface, with ppp(8). I have a default route via 217.5.*.* gateway on
tun0 (both the default route and the host route for this 217.5.*.*
gateway use device tun0).

"route get 1.2.3.4" prints that 1.2.3.4 is routed via some 217.5.*.*
host which is on tun0, so this looks fine.

I'd expect that the "in via tun0" matched the outbound route as returned
by route get.

To add to the confusion, NTP (that uses UDP) is fine, the machine will
synchronize to an outside server (my ISP's DCF receiver) via the same
gateway just fine.

Is my expectation wrong or is there a pertinent IPFW2 bug in a current
5.2-BETA kernel?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95