Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 6 Apr 2000 16:56:28 -0400
From:      "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com>
To:        Mike Heffner <spock@techfour.net>
Cc:        freebsd-ipfw@FreeBSD.ORG
Subject:   Re: Problems with natd
Message-ID:  <20000406165628.C4198@cc942873-a.ewndsr1.nj.home.com>
In-Reply-To: <XFMail.20000405020339.mheffner@mailandnews.com>; from mheffner@mailandnews.com on Wed, Apr 05, 2000 at 02:03:39AM -0400
References:  <20000404231711.A40889@cc942873-a.ewndsr1.nj.home.com> <XFMail.20000405020339.mheffner@mailandnews.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 05, 2000 at 02:03:39AM -0400, Mike Heffner wrote:
[snip]
> natd.conf file:
> 
> interface ed0
> same_ports yes
> dynamic yes

Seems OK. I always like to add "unregistered_only."

> ipfw rules:
> 
> 00010 176 14949 count log ip from any to any
> 00015  24  2634 allow ip from any to any via lo0
> 00100   0     0 allow ip from any to any via ep0
> 00200   6   248 divert 8668 ip from any to any via ed0
> 00300  57  6332 allow ip from any to any
> 65535   1    28 deny ip from any to any

Wide open for testing, good. One thing I'm curious about, and I really
don't know if this has anything to do with the problem, is why the
'count' rule does not sum up to all of the rules below it.

> $ ifconfig -a
> ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet a.b.c.d netmask 0xffffff00 broadcast 255.255.255.255
                                                    ^^^^^^^^^^^^^^^
Is that the real value or did you mask that?

>         ether 00:40:05:63:46:3d 
> ep0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>         inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
>         ether 00:20:af:a1:05:8b 
>         media: 10baseT/UTP
>         supported media: 10baseT/UTP
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
>         inet 127.0.0.1 netmask 0xff000000 
> 
> [a.b.c.d == outside, real, ip]
> 
> $ netstat -rn
> Routing tables
> 
> Internet:
> Destination        Gateway            Flags     Refs     Use     Netif Expire
> default            a.b.c.d            UGSc       19       94      ed0
> 10/24              link#2             UC          0        0      ep0 =>
> 127.0.0.1          127.0.0.1          UH          1       20      lo0
> a.b.c              link#1             UC          0        0      ed0 =>
> a.b.c.d            0:d0:58:c7:98:38   UHLW       19        0      ed0   1200

Looks OK provided a.b.c.0 is an historic C Class net.

> also, here is part of a natd verbose output log, first part is successful
> ICMP'ing, second is an unsuccessful ftp connect attempt:
> 
> Out [ICMP] [ICMP] a.b.c.d -> e.f.g.h 8(0) aliased to
>            [ICMP] a.b.c.d -> e.f.g.h 8(0)
> In  [ICMP] [ICMP] e.f.g.h -> a.b.c.d 0(0) aliased to
>            [ICMP] e.f.g.h -> a.b.c.d 0(0)
> Out [ICMP] [ICMP] a.b.c.d -> e.f.g.h 8(0) aliased to
>            [ICMP] a.b.c.d -> e.f.g.h 8(0)
> Out [ICMP] [ICMP] a.b.c.d -> e.f.g.h 8(0) aliased to
>            [ICMP] a.b.c.d -> e.f.g.h 8(0)
> Out [ICMP] [ICMP] a.b.c.d -> e.f.g.h 8(0) aliased to
>            [ICMP] a.b.c.d -> e.f.g.h 8(0)
> In  [ICMP] [ICMP] e.f.g.h -> a.b.c.d 0(0) aliased to
>            [ICMP] e.f.g.h -> a.b.c.d 0(0)

What one expects when pinging from the NAT machine, good.

> Out [TCP]  [TCP] a.b.c.d:1026 -> e.f.g.h:21 aliased to
>            [TCP] a.b.c.d:1026 -> e.f.g.h:21
> Out [TCP]  [TCP] a.b.c.d:1026 -> e.f.g.h:21 aliased to
>            [TCP] a.b.c.d:1026 -> e.f.g.h:21
> Out [TCP]  [TCP] a.b.c.d:1026 -> e.f.g.h:21 aliased to
>            [TCP] a.b.c.d:1026 -> e.f.g.h:21
> Out [TCP]  [TCP] a.b.c.d:1026 -> e.f.g.h:21 aliased to
>            [TCP] a.b.c.d:1026 -> e.f.g.h:21
> 
> 
> [ a.b.c.d == my ip address
>   e.f.g.h == an internet server ip ]

Hmmm... NOT what one expects. It does not look like anything is ever
coming back. My first inclination would be to guess that there is a
firewall rule blocking setups on port 21 in front of natd's divert
rule, but if your output above is accurate, this is not the case.

If you were not getting ICMP packets back, I would guess that
something at or behind your coax modem was not routing properly. Does
a tcpdump show the same thing as the natd log for the TCP connection
attempt? Of course, there is always the question, maybe e.f.g.h is
dropping attempts at 21?
-- 
Crist J. Clark                           cjclark@home.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000406165628.C4198>