[ previous ] [ next ] [ threads ]
 
 From:  "Bruce A. Mah" <bmah at acm dot org>
 To:  Jukka Salmi <j+m0n0wall at 2004 dot salmi dot ch>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] interfering filter rule
 Date:  Fri, 23 Jul 2004 08:03:03 -0700
On Fri, 2004-07-23 at 07:37, Jukka Salmi wrote:

> because I'd like to filter IPsec VPN traffic I set up m0n0wall as a
> filtering bridge between LAN and another m0n0wall box (which acts as
> the default gateway for LAN hosts):
> 
>     inet|-------|m0n0-gw|-----|m0n0-br|-----|LAN
>                WAN     LAN   OPT1    LAN
>                     |
>           v.w.x.y/z |     192.168.0.0/24
>          -----------+---------------------------

For future reference:  It took me awhile to figure out that the above
means that m0n0-gw's WAN interface is v.w.x.y./z and everything to the
right is supposed to be a part of 192.168.0.0/24.  At first I thought
the vertical line was another network.

I'm probably going to get over my head pretty quickly here because it's
been quite awhile since I seriously thought about this feature.  Here
goes...

> On m0n0-gw I redirect some port to LAN hosts. Even though m0n0-br
> has explicit rules to let these connections pass they are blocked
> because of an automatically generated rule wich is evaluated
> earlier:
> 
> 	block in log quick on sis2 from !192.168.0.0/24 to any
> 
> (sis2 is the OPT1 interface)
> 
> Removing this rule solves the problem.
> 
> Is this a bug in m0n0wall or am I missing something?

I don't think you're missing anything, but the filtering bridge rules
were set up for a slightly different configuration than what you have.

<speculation>

If OPT1 is the unnumbered bridge interface, the rules generator might be
trying to generate the anti-spoofing rules corresponding to the other
side of the bridge (the LAN interface).  This would be consistent with
the rule you showed above.

On my m0n0wall box, which I claim to be the canonical setup for filtered
bridging (:-)), I have my OPT1 interface as an unnumbered interface
bridged to the WAN interface.

The difference is that, I think, the LAN interface is designed to be
facing a stub network (i.e. the only traffic arriving on the LAN
interface should be originated by hosts on that subnet), where the WAN
interface isn't (it's allowed for traffic to arrive on the WAN interface
with source addresses from almost anywhere).

So one thing to try might be to reconfigure m0n0-br with a WAN interface
facing towards m0n0-gw and its OPT1 interface facing towards your LAN. 
Bridge the OPT1 interface to the WAN.

</speculation>

Caveat:  I wrote all of the above email without actually looking at the
rulesets or rule generator code, and I haven't looked at either for over
half a year.  So this could be completely wrong.

Good luck...I look forward to hearing how this works out.

Bruce.
signature.asc (0.2 KB, application/pgp-signature)