[ previous ] [ next ] [ threads ]
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Help passing traffic from LAN to OPT1
 Date:  Sat, 10 Jul 2004 14:42:38 -0700 (PDT)
On Sat, 10 Jul 2004, Joe Lagreca wrote:
> Ok, the problem has evolved.  The only device on OPT1 before was the
> AP, but now I connected OPT1 to a switch and have the AP plugged into
> the switch along with another computer.
> > The first rule, if it were needed, would need to be in the LAN section,
> > not the OPT1 section.  The concept is that the rules determine what
> > traffic origination is allowed *in* from a given interface.  However, if
> > you have the default rule allowing traffic from LAN to anywhere, then it's
> > superfluous.
> I am now very confused about m0n0 firewall rules.  Here are my rules for:
> OPT1 interface
> Proto   Source     Port    Destination      Port     Description  
>  *        OPT1 net   *        ! LAN net         *         Default OPT1
> -> WAN but not LAN

The "! LAN net" part means that traffic from OPT1->LAN is blocked.  That's
often desirable, but you should at least allow ICMP so you can test with

> Is it good security practice to also include a rule at the bottom of
> any interface list to deny everything but what was explicity allowed
> above?  Or do I have the whole concept wrong?

In general, yes, but m0n0wall already does this.  In fact, it does it at
two levesl, since it stes the overall default policy to "deny" and
additionally adds explicit "deny" rules at the bottom of the list.  Both
levels are internal and not visible in the GUI, although the second is
visible in ipfstat.

See below for why it may not appear that this is the case.

> > You also haven't answered my question about what default gateway is
> > configured *in the AP*.  If that's anything other than the m0n0wall's OPT1
> > IP, then packets from the AP to the LAN won't route correctly.  This can
> > be worked around with NAT, but that's the less desirable choice.
> I believe this is where my whole problem was.  There is no gateway
> setup in the AP, and I don't believe it is possible.  I configured the
> AP's LAN address to be with subnet mask of

That sounds like a serious problem.

> Above I mentioned I now have another device on OPT1.  The BIG NEWS is
> that I can ping it from LAN!  Which mostly means my problem is solved.
>  However the question still remains, how can I ping the computer on
> OPT1, but not the AP?  Is it simply because the AP doesnt have a
> gateway setup for its LAN?

Of course.  The AP only has an "automatic" route for directly-connected
machines.  For anything else, it needs to have a "default gateway" to
route through, and *that* IP needs to be directly connected, i.e. within
the same block defined by the netmask.

First I'd dig into the AP further to see if it's really true that it can't
have a default gateway.  For example, it might not have the term "default
gateway", but allow you to configure a gateway IP of (which is
how most systems represent it internally, anyway).  If it doesn't use CIDR
notation, then that woould be netmask

Another issue is whether the AP will be operating as a bridge or as a
router.  In the former case, the AP's configuration only affects the
ability to communicate with the AP itself, and the ability of the WLAN
clients to work would depend on whether *they* see the m0n0wall as the
default gateway.  In the latter case, they would need to see the AP as
their default gateway, and the AP would need to see the m0n0wall as such.  
BTW, if the AP operates as a router and doesn't have a default gateway,
then the clients wouldn't be able to acces the Internet, either, even if
the m0n0wall weren't there.

If you do need IP connectivity between the LAN and the AP (for real client
traffic) *and* can't set up its default gateway properly, then you
probably need Proxy ARP.  NAT could be configured to handle LAN->WLAN
connections, but it wouldn't be practical for WLAN->WAN.  With this
approach, the LAN and OPT1 would need to appear as the *same* subnet to
the AP, and all accessible LAN machines would need Proxy ARP entries on
the OPT1 side.  In order to avoid having to do this in reverse as well,
you'd want to choose the addresses carefully so that the LAN subnet is a
sub-subnet of the LAN/OPT1 combo.  With ..50. addresses on LAN and ..51.
addresses on OPT1, this would work if you defined the OPT1 as /23 but kept
/24 for the LAN.  The m0nowall would do CIDR-style "best match" routing
and thus select LAN for anything in the LAN range, even if it also matched
OPT1.  The LAN machines would still see the OPT1 subnet as "foreign" and
route through the m0n0wall.  Only the OPT1 side would be confused about
what's "local" and need Proxy ARP to help it out.

*But*, if the AP operates as a bridge and the only need for IP
connectivity to the AP itself is for configuration and monitoring
purposes, then you can set up a NAT mapping "using "Advanced Outbound
NAT" to make LAN machines appear to be the m0n0wall itself when accessing
the AP.  Note that if you enable "Advanced Outbound NAT", the default
LAN->WAN mapping rule isn't included by default and must be added
explicitly.  It would probably be better if this happened automatically.

There also seems to be a bug in selecting an outbound NAT rule for
editing.  I currently have two, and whichever one I click on to edit, it
gives me the other.  But if I select the "wrong" one, I can edit the
intended one just fine.

> > There are a number of things that make this case more complicated than
> > just inserting a firewall/router between WAN and LAN, some of which are
> > m0n0wall-specific and some of which aren't.  The only m0n0wall issue that
> > I consider a mistake is the inappropriate default netmask on OPT1.  
> I couldn't agree more.  Actually when assigning an IP to any
> interface, it should default to a netmask such as /24 or some other
> commonly used network.

Ideally it would default to the proper netmaks for the address class, but
without relying on Javascript there's no way it could pick the right
number in the popup.  However, the popup could have a "default" option.

On Sat, 10 Jul 2004, Dinesh Nair wrote:
> On Sat, 10 Jul 2004, Joe Lagreca wrote:
> > I am now very confused about m0n0 firewall rules.  Here are my rules for:
> have you applied to the rules and/or rebooted your m0n0 after creating the
> rules below ?
> >
> > OPT1 interface
> > Proto   Source     Port    Destination      Port     Description
> >  *        OPT1 net   *        ! LAN net         *         Default OPT1
> > -> WAN but not LAN
> >
> > LAN interface
> > Proto    Source     Port     Destination     Port    Description
> > *          LAN net     *          *                    *
> > Default LAN -> any
> >
> > The rule for OPT1 (reading from top down) will allow traffic from OPT1
> > to pass to any interface, except LAN.
> exactly, which would prevent you being able to ping any boxen hanging off
> OPT1.

No, that's not true.  The "pass" rules become "keep state" rules
internally.  When a LAN->OPT1 ping is allowed, it creates a state entry
that allows the response to get through regardless of any rules.  It's
only *initiating* a ping from OPT1->LAN that wouldn't work with the above
rules, though I'd recommend adding a rule to allow this as well.

> > Above I mentioned I now have another device on OPT1.  The BIG NEWS is
> > that I can ping it from LAN!  Which mostly means my problem is solved.
> which is odd, considering that you have a rule which prevents the ICMP
> replies to go back to the LAN by blocking all packets from OPT1 Net to LAN
> Net.

Not odd at all, see above. :-)

I think the real problem is routing, not the firewall.

					Fred Wright