Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 8 Mar 2001 04:26:52 -0600
From:      Bill Fumerola <billf@mu.org>
To:        Patrick O'Reilly <patrick@mip.co.za>
Cc:        FreeBSD Network List <freebsd-net@freebsd.org>, FreeBSD IPFW List <freebsd-ipfw@freebsd.org>
Subject:   Re: FW: MS Shares through IPFW
Message-ID:  <20010308042652.Q31752@elvis.mu.org>
In-Reply-To: <NDBBIMKICMDGDMNOOCAIOEAJCEAA.patrick@mip.co.za>; from patrick@mip.co.za on Thu, Mar 08, 2001 at 11:47:45AM %2B0200
References:  <NDBBIMKICMDGDMNOOCAIOEAJCEAA.patrick@mip.co.za>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 08, 2001 at 11:47:45AM +0200, Patrick O'Reilly wrote:

> In my desperation I have gone as far as adding these two very loose rules,
> which are the very first rules in the ipfw chain:
> --------
> /sbin/ipfw -q add 00009 allow log ip from 10.5.5.0/24 to 10.3.3.240
> /sbin/ipfw -q add 00009 allow log ip from 10.3.3.240  to 10.5.5.0/24
> --------
> 
> The 10.5.5.0/24 Subnet includes the client we are testing, and 10.3.3.240 is
> the NT Server.  The 10.5.5.0/24 Subnet is remote across a VPN, but there are
> IP tunnels in place so that the extra hops are transparent -> I don't THINK
> they should be causing our problems.

"Transparent" hops wouldn't be the problem. IP packets coming across the wire
don't know the difference, neither does ipfw.

> When the Client tries to map the share on the Server there is a whole bunch
> of traffic logged against rule #9, including ports UDP 137 and TCP 139,
> going back and forth between the client and server.  The client is prompted
> for a login/password, which we enter VERY CAREFULLY to make sure we got it
> right, but thereafter the connection is refused.

If the client is prompted for a login/password it would seem that a connection
has been established (and the firewall doesn't seem to be the problem).

If you REALLY want to know what makes this windows crap tick, put the two
clients on the same subnet (on a hub, that makes this easy) and make your
connection and have a sniffer like tcpdump or (if you're running X) ethereal.
You'll get the entire picture and know exactly what rules to write instead of
bogusly allowing * (if protecting those subnets is a goal).

> --------
> Mar  7 11:16:08 eccles /kernel: ipfw: 65534 Deny UDP 0.0.0.0:68
> 10.3.3.240:67 in via rl2
> 
> I believe ports 67 and 68 are used for DHCP - we are not using DHCP
> anywhere, so I don't understand why this pops up, but I include it as it may
> be relevant ?!?  Also, why is the source IP on the first line 0.0.0.0 ?

What is the IP of a machine that has no IP (hint: and is looking for one..)?

-- 
Bill Fumerola - security yahoo         / Yahoo! inc.
              - fumerola@yahoo-inc.com / billf@FreeBSD.org




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




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