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
<shellcmd>/sbin/ifconfig rl0 172.17.17.1 netmask 0xffffff00
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:
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.
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: 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
The unanswered question is: Why does the echo reply get caught in the
Checking 'bypass rules for packets on LAN' does solve the problem.