Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Sep 2001 21:17:54 -0500
From:      David Kelly <dkelly@hiwaay.net>
To:        Bradley Oedithipus <bradley@lightstep.org>
Cc:        freebsd-questions@FreeBSD.ORG
Subject:   Re: natd/ipfw/sshd problem. 
Message-ID:  <200109260217.f8Q2Hsw17873@grumpy.dyndns.org>
In-Reply-To: Message from Bradley Oedithipus <bradley@lightstep.org>  of "Tue, 25 Sep 2001 18:33:17 CDT." <Pine.BSF.4.32.0109251830230.2320-100000@lightstep.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
Bradley Oedithipus writes:
>
> lightstep:~ # ipfw -a l
> 00050  1933  595146 divert 8668 ip from any to any via ed0
> 00100 19894  995402 allow ip from any to any via lo0
> 00200     0       0 deny ip from any to 127.0.0.0/8
> 00250   108    6213 allow tcp from 10.0.0.0/8 to 66.100.232.202 143
> 00300    23    1260 unreach host tcp from any to 66.100.232.202 143
> 00500    17     972 unreach host tcp from any to 66.100.232.202 139
> 65000 40851 7434737 allow ip from any to any
> 65535    27    1801 deny ip from any to any
> lightstep:~ #

I find it interesting that somehow 27 packets got past 65000. Can only 
assume not all of the above rules were added at the same time.

Clear the ipfw counters with "ipfw zero". If 65535 still gets hits then 
insert "ipfw add 65100 deny log ip from any to any" and watch 
/var/log/security in an xterm. Figure out exactly what packet, address, 
and port, is having the problem. If its re-written by natd you'll see 
the changed addresses.

Won't hurt to include a specific allow for incoming ssh:

00800 allow tcp from any to any established
01400 allow log tcp from myself.at.home to any 22 setup

Another way to approach the problem would be to insert the following so 
that you could debug what is happening at 65000:

1000 allow tcp from any to any established
1100 allow log tcp from any to any setup

The above only traps the connection (attempt?) for logging. Unless you 
have logging disabled in ipfw the output can be watched with  
"tail -f /var/log/security", or I favor the F command in less(1).

Another thing I have done is to run "natd -v" to prevent it from 
becoming a daemon. Output is written to stdout. Throw your ssh 
connection at it in this state and see what natd has to say about it.

I find the following is useful as an /etc/natd.conf:

log_facility security
log_denied yes
dynamic yes
use_sockets yes
same_ports yes
punch_fw 2610:90

The punch_fw option inserts ipfw rules starting at 2610 (or 2611?) for 
ftp and irc connections by monitoring the setup data stream on the Well 
Known Port. Bites me when attempting passive ftp but works great the 
old fashioned ftp way.

-- 
David Kelly N4HHE, dkelly@hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.



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




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