I deleted the route I had from LAN 192.168.0.0 to OPT1 192.168.5.0 and
now the m0n0wall can't seem to ping anything on OPT1 (192.168.5.1 or
PING 192.168.5.1 (192.168.5.1): 56 data bytes
--- 192.168.5.1 ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
When I do a traceroute from 192.168.0.40 to 192.168.5.5 this is what I get:
C:\Documents and Settings\Joe>tracert 192.168.5.5
Tracing route to 192.168.5.5 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms firewall.humboldt.no-ip.com [192.168.0.1]
2 11 ms 6 ms 8 ms 10.7.108.1
3 10 ms 7 ms 7 ms 126.96.36.199
4 * * * Request timed out.
5 * * * Request timed out.
This probably has something to do with NAT, because it should just got
from LAN to OPT1 without having to go out to the internet. However I
dont know what to change in my NAT to correct this.
Under NAT I have a bunch of inbound WAN ports pointing to devices on
my LAN. Server Nat, 1:1, and Outbound all have nothing in them.
The firewall allows everything out from OPT1 and everything from LAN
into OPT1. LAN allows everything out from LAN. This should be plenty
to allow me to ping from LAN to OPT1.
Just from the traceroute it looks like I have something really screwed
up with the routing or NAT. Do you have any ideas on what I should
I'm sorry if I sound inexperienced or incompetent. It may be a
combination of the two. But I'm trying, and I REALLY appreciate your
On Wed, 30 Jun 2004 15:31:40 -0700 (PDT), Fred Wright <fw at well dot com> wrote:
> On Tue, 29 Jun 2004, Joe Lagreca wrote:
> > My m0n0wall is the default gateway and router for all of my networks,
> Including the AP?
> > so I guess that means I can remove the static route I created to get
> > from LAN to OPT1. It sounds like in my case no static route is
> > needed.
> That's what I would expect.
> > I think I have my setup as a basic NAT between my LAN and WAN. I then
> > added another NIC, and ran into this mess. How should I have my
> > routing setup between all three interfaces?
> The likely problems are:
> 1) Routing. Make sure every machine on network A (or initially, the one
> you're testing with) has the m0n0wall as the route to network B (being the
> default gateway is good enough unless overriden by something more specific
> that matches the destination). This needs to be true for both A->B and
> B->A cases.
> 2) Firewall. Make sure your config is allowing ICMP (at least) between
> LAN and OPT1. Theoretically you only need to allow the "request"
> direction and the stateful filter should pass the reply, but for this kind
> of testing you probably want it to work both ways, anyway. Besides, in
> most cases blocking ICMP is excessively paranoid.
> 3) NAT. You probably don't want NAT between LAN and DMZ, and even if you
> had it it *shouldn't* keep pings from working, but it's something to be
> aware of.
> If the two machines used for testing can run tcpdump, then you can
> actually trace the packets to see where they make it and with what
> > > I just added another NIC to my m0n0wall to create a DMZ for my wireless
> > > network. Here is a quick rundown of my network:
> > >
> > > LAN: 192.168.0.1
> > > OPT1: 192.168.5.1
> > >
> > > I can ping OPT1 interface from LAN, but not 192.168.5.5, which is the
> > > address of my AP. I can ping the AP from the m0n0wall.
> Well, you're not really "pinging the OPT1 interface" from the LAN - you're
> simply pinging the m0n0wall at one of its IP addresses that happens to be
> derived from the OPT1 interface. But I doubt that the interface is the
> problem, anyway.
> Fred Wright
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch