[ 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, 3 Jul 2004 15:44:50 -0700 (PDT)
On Wed, 30 Jun 2004, Joe Lagreca wrote:

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

I presume you meant you deleted it in the m0n0wall config, but since this
test involves at least three machines, it's best to be more explicit.

> Ping output:
> 
> 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  68.6.10.154
>   4     *        *        *     Request timed out.
>   5     *        *        *     Request timed out.

This is consistent with the m0n0wall's not having a route to 192.168.5.5.

When you configured the OPT1 interface, you didn't by any chance accept
the default (and technically illegal) /31 netmask, did you?  That would
definitely cause this kind of trouble.  In your setup you probably want
/24, which, among other things, tells the m0n0wall that 192.168.5.*
addresses are directly reachable on that interface.

To check m0n0wall's routing table, do "netstat -rn" via exec.php.

There are a couple of things to be aware of with traceroute:

1) Even with correct routing, you may see "holes" if the machine in
question doesn't return proper ICMP errors.  In particular, if the target
machine doesn't, then the traceroute will appear to be "dead forever" at
and beyond that machine.

2) NATted traceroute is broken in m0n0wall 1.1b14, due to its screwing up
the ICMP checksums in NAT processing.  This worked properly in 1.0, so I
suspect it relates to the ICMP checksum "fixes" in IPFilter between 3.4.31
and 3.4.32, but haven't identified the exact bug yet.

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

In the quick check I just did, it appears that by default the OPT1
interface is regarded as "LAN-like" for NAT purposes, so NAT shouldn't be
applied between LAN and OPT1.  To verify this, do "ipnat -l" in exec.php
and see what interface(s) has/have NAT applied.

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

I presume this includes not enabling "Advanced Outbound NAT".

					Fred Wright