Well ... assuming you are correct that this DENY is associated with the ftp attempt ... your ftp server, or some related application (like tcp wrappers) on the system it is running on (192.139.75.6), is sending an ident query to the client (192.139.75.156 in the log entry you posted) you are trying to connect from. That query is blocked by the firewall with a DENY. Eventually (30 seconds, as you report it), the ftp server (or the related app) gets tired of waiting for a reply, times out the ident request, and lets you connect anyway.
Since both source and destination addresses are on the same /24 network, I'm a bit uncertain about what the router is routing. So I don't know if the ident request is being misrouted to the LEAF/DachStein router or if your address space is being subnetted in a fashion that calls for this routing. For now, I'll assume the second -- that the routing is OK and the only problem is with the router not passing the packet on. Even so, since you use Seawall and I don't, I'm going to have to leave it to someone who does use Seawall to give you the specific fix. The rest of these comments pertain to ipchains generically. In general terms, the most likely solution is to add a rule that ACCEPTs traffic to port 113 from the internal side (or at least from the ftp host), and *perhaps* a rule that ACCEPTs responses from port 113 to the ftp server (whether you need this or not depends on what the rest of your ruleset is). Or you could replace the rule that DENYs the port-113 query with one that REJECTs it. This should cause the ftp server to know right away that the query is unsuccessful, instead of having to wait for it to timeout; then, since it is willing to connect without an ident response, it should connect more quickly. (But the REJECT rule might not work; firewall REJECTs are different from tcp-stack REJECTs, and not all receiving hosts recognize them correctly. If this be true in your circumstances, I don't believe there is a workaround available.) Or you could modify the ftp host so it does not generate ident queries to authenticate connections. Since I know nothing about this host -- like what OS is uses, what ftp server package, and what if any intermediate security wrapper -- I don't know if this option is even feasible, let alone the details of how to do it. BTW, I think the Echogent suggestion that " ... it's likely someone trying to take advantage of your system in some manner" is simply wrong (sorry, Scott). It doesn't apply to your situation in any case (the ident request is coming *from* your LAN, though that is not apparent from the packet log viewed by itself, without your clarifying comments). Even if the DENY'd packet were coming from outside, ident requests are common enough that the interpretation is implausible even in that case. At 10:22 AM 11/28/01 -0600, Troy Aden wrote: > When I attempt to ftp our server (192.139.75.6) it was taking up to >30 sec to connect. (It should take 2 sec) I turned on logging and this is >the output. > >Nov 27 22:12:12 firewall kernel: Packet log: remote DENY eth0 PROTO=6 >192.139.75.6:1083 192.139.75.156:113 L=60 S=0x00 I=19689 F=0x4000 T=63 SYN >(#10) > > I went to http://www.echogent.com/cgi-bin/fwlog.pl ><http://www.echogent.com/cgi-bin/fwlog.pl> and this is what it told me. >A TCP packet to this port (113) is associated with the ident service. If >you're running this service on your firewall or on your LAN, with the >intention of offering external access to it, then your firewall may be >mis-configured. If you're *not* running this service, and have no idea what >it is, it's likely someone trying to take advantage of your system in some >manner. You may want to investigate 192.139.75.6 further and see if there's >an Administrative Contact there whom you could email this packet log to. > I am running Dachstein rc2. with Seawall 4.1. I have ftp_masq >enabled. Anyone have any ideas as to what is happening here? > -- ------------------------------------"Never tell me the odds!"--- Ray Olszewski -- Han Solo Palo Alto, CA [EMAIL PROTECTED] ---------------------------------------------------------------- _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
