I believe that stateful inspection should only be applied to RETURN packets from the 172.16.0.0-net
You probably have a pass rule on the LAN interface looking something like this:
"pass in quick proto tcp from 192.168.1.0/24 to 172.16.1.1/32 port = 22 keep state"
That should ensure that ANY ssh packets from LAN to 172.16.1.1 are passed - no matter the state.
m0n0wall will inspect return packets from 172.16.1.1 to LAN - and (hopefully) pass them according to
the implicit allow through "keep state" in the aforementioned rule.
(I'm still a newbie when it comes to networking - so I may be completely off here).
From: Michael Østergaard Pedersen [mailto:michael at bytopia dot dk]
Sent: 16. maj 2004 19:25
Subject: Re: [m0n0wall] Problem with static routes
Rule 68 is this one:
@68 block in log quick proto tcp from any to any
Which seems to be the default block rule.
I have thought about a possible cause if this problem. Please correct me if
I am wrong.
When I try to establish the SSH session to 172.16.1.1 my machine has
previously received an ICMP redirect telling it to use 192.168.1.254 as the
nexthop. As long as only a few bytes are sent it seems to use this
information. However, something strange happen when I have to send more data
(which happens after the SSH login is accepted and I get a shell) because
now it uses the m0n0wall instead of 192.168.1.254 as the nexthop (this has
been confirmed using tcpdump). It's a SUSE Linux 9.0 box and I have no idea
why it suddenly don't use the information from the ICMP redirect message
Since the TCP connection was established through 192.168.1.254, when the
m0n0wall sees a TCP packet for 172.16.1.1 for which it has never seen the
SYN packet used to set up the connection it is dropped because m0n0wall is a
stateful firewall and it doesn't recognise the connection.
If this is the case there don't seem to be anything that m0n0wall can do. It
is a firewall - not a router.