[ previous ] [ next ] [ threads ]
 
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  Alan Schmitz <alan at ankeny dot net>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Problem with Bridging and NAT
 Date:  Sat, 20 Dec 2003 10:13:51 +0100
On 20.12.2003, at 05:37, Alan Schmitz wrote:

> That rule looks like:
>
>    @12 block in quick proto tcp from any to any
>
> which seems awfully generic.  Without much of an understanding of how 
> the rules are supposed to work together, I'd have to guess that the 
> packets aren't supposed to get that far down the list of rules.

Nope - here's how this rule is generated in filter.inc:

--
# Block TCP packets that do not mark the start of a connection
skip 1 in proto tcp all flags S/SAFR
block in quick proto tcp all
--

(the "all" is translated to "from any to any" by ipfilter)

These two rules serve to block all packets that have anything else but 
the SYN flag out of SYN, ACK, FIN and RST set. If the packet really is 
a TCP SYN packet, then the block rule is skipped (two rules are 
necessary because it isn't possible to say "not S/SAFR" in ipf rule 
language).

Remember that the ruleset is only evaluated for the first packet of 
each connection (with very few exceptions), and if it is passed, it 
creates an entry in the state table that causes all further packets 
belonging to the same connection to be passed in both directions 
without going through the ruleset anymore. If it weren't for these two 
rules, any TCP packet could create a state table entry, leaving you 
open to attacks involving not adhering to the TCP three-way handshake 
(i.e. FIN scanning and the likes) if you have any ports open to the 
outside.

> Until I learn more about how these rules work, I think I'll have to 
> assume that the NAT isn't recognizing return traffic that comes 
> through a bridged interface which isn't included in the NAT state.

This is probably your problem: m0n0wall does stateful packet filtering, 
and as such traffic must flow through the filter in both directions for 
it to work. This is a design choice.

Well, bridging really interacts in a nasty way with filtering and NAT. 
Maybe your LAN -> DMZ traffic is NATed before being bridged to the DMZ 
interface, but for some reason the replies aren't? Just a wild guess. 
If it weren't for the few applications where it actually makes sense to 
use bridging, I'd remove it from m0n0wall. ;) Maybe you should consider 
using 1:1 NAT for your DMZ server needs instead... it's much more 
straightforward.

- Manuel