This is your typical 'it doesn't work' posting, only I actually tried 
figuring out what was going on beforehand, and I've worked around it. Now I 
want to know exactly why.

Summary: packets going in and out of the same interface gets dropped 
regardless of rules.

The setup is as follows:
The company has three networks. The DMZ, the Corp network, and the 
production network. The m0n0 is sitting between the DMZ and Corp, and has a 
static route to the router between Corp and Production. Corp is managed 
switches, so it's sniffable.

   (internet)-- m0n0 --(corpnet)-- poductionrouter --(production)

To complicate the setup slightly, there are 2 additional ip ranges on 
corpnet, added to the config xml.

  <shellcmd>/sbin/ifconfig rl0 172.17.18.1 netmask 0xffffff00 
alias</shellcmd>
  <shellcmd>/sbin/ifconfig rl0 172.17.17.1 netmask 0xffffff00 
alias</shellcmd>

And a set of firewall rules to get it to act as a bouncer when clients on 
Corpnet try to access production

  allow any from Corp to 172.16.0.0/12
  allow any from Corp to Production
  allow any from 172.17.17.0/24 to corp
  allow any from 172.17.18.0/24 to corp
  allow any from Production to Corp

Until yesterday we were running 1.11, it worked so we didn't change it.
After changing over to 1.21 we became unpopular:

This works:
When a machine on Corp tries to talk to a machine on Production, it sends 
the SYN/echo/.. to m0n0, and m0n0 replies with a redirect. The original host 
then sends another SYN to productionrouter, and productionrouter sends a 
packet on productionnet. When the reply comes back, productionrouter sends 
the reply directly to the machine. I can see the temporary routing entry in 
the originating host's routing table. Perfect.

This doesn't:
When a machine on productionnet sends a packet, SYN or PING, to a machine on 
Corp, it goes to productionrouter as it should, and productionrouter then 
sends it to the machine on Corp. This then replies with a SYNACK or 
echoreply to m0n0, and m0n0 drops it.
192.168.69.120 is a machine on productionnet, 192.168.10.10 is a machine on 
Corpnet sending the echo reply:

ipmon[124]: 17:04:19.923197 rl0 @100:9 b 192.168.10.10 -> 192.168.69.120 PR 
icmp len 20 60 icmp echoreply/0 K-S K-F IN

Not even a catch-all rule in the the very first place on the LAN rulepage 
helps.
        <rule>
            <type>pass</type>
            <interface>lan</interface>
            <source>
                <any/>
            </source>
            <destination>
                <address>192.168.0.0/16</address>
            </destination>
            <log/>
            <frags/>
            <descr>lokalnet trafik</descr>
        </rule>

The unanswered question is: Why does the echo reply get caught in the 
spoofing(?) filter?

/Kasper Pedersen

status.php: http://www.kasperkp.dk/m0n0wall%20status.htm

Checking 'bypass rules for packets on LAN' does solve the problem.