[ previous ] [ next ] [ threads ]
 
 From:  "Martin Holst" <mail at martinh dot dk>
 To:  =?iso-8859-1?Q?Michael_=D8stergaard_Pedersen?= <michael at bytopia dot dk>
 Cc:  "M0n0wall" <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] Problem with static routes
 Date:  Sun, 16 May 2004 20:36:54 +0200
Hi Michael!

I believe that stateful inspection should only be applied to RETURN packets from the 172.16.0.0-net
to LAN.

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).

/Martin

-----Original Message-----

Sent: 16. maj 2004 19:25
Cc: M0n0wall
Subject: Re: [m0n0wall] Problem with static routes

Hi Martin,

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 
anymore.

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.

Regards,
Michael