You have rulesets in place that will pass state NEW SMB packets both ways between the firewall and the LAN. They are in these rule sequences:

14 2109 eth1_in ah -- eth1 * 0.0.0.0/0 0.0.0.0/0
(in INPUT)
14 2109 loc2fw ah -- * * 0.0.0.0/0 0.0.0.0/0
(in eth1_in)
14 2109 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpts:137:139
(in loc2fw)

-- confirms that some incoming SMB packets are being passed to the router from the LAN.

14 2109 fw2loc ah -- * eth1 0.0.0.0/0 0.0.0.0/0
(in OUTPUT)
14 2109 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state NEW udp dpts:137:139
(in fw2loc)

-- confirms that some outgoing SMB packets are being passed from the router to the LAN.

But being a bit hazy on how SMB works, I wonder if perhaps you need to pass state ESTABLISHED or RELATED packets as well as state NEW? I do note that the OUTPUT chain has a DENY policy, and that policy has blocked 21 packets. They don't get logged, so we don't know what they are (though the final reject rule leaves me a bit puzzled about how *any* packets can reach the DENY policy here).

I did look back at your original report and note from it that the error is associated with retransmitting packets, not with originating them. For example:

[2002/12/02 16:58:04, 0] libsmb/nmblib.c:send_udp(756)
Packet send failed to 192.168.1.255(137) ERRNO=Operation not permitted
[2002/12/02 16:58:04, 0] nmbd/nmbd_packets.c:retransmit_or_expire_response_records(1655)
retransmit_or_expire_response_records: Failed to resend packet id 3319 to IP 192.168.1.255 on subnet 192.168.1.254
Perhaps someone who knows the workings of Samba better than I can comment on whether my suggesting this possibility is useful or silly?

One final suggestion -- you might consider checking the rulesets again (either in this fashion or the one Tom suggested, though I don't know if I'll be able to interpret Shorewall-specific reports) after some time has elapsed, just to be sure that the Samba retransmit failures have actually occurred ... the packet counts in what you posted were generally low, implying that the firewall had not been active for very long, possibly not long enough for the problem to occur.

At 06:12 PM 12/3/02 +0900, youngdo wrote:
[details deleted]


--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------



-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET comprehensive development tool, built to increase your productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to