On Fri, 2004-01-02 at 07:01, Rigler, Steve wrote: > You need to connect to a client on a different subnet. You know the client's > ip address, but not the netbios name. You can send a query to the client > using nmblookup but, again, according to rules defined, the client's two > UDP packets sent from port 137 to some random high port are dropped. Nothing is random. Isn't this the port of the client who made the query? I believe in Windows this originates from port 137 but on Linux it is whatever port the querying application is running. > So, what do you do to circumvent this? Do you resort to maintaining static > hosts entries for every machine with which you interact? Not exactly elegant, > but evidently it can work. WINS is great. I mentioned LMHOSTS to note that Samba needs a way to translate the netbios name to an IP address. > How about a rule based on state, which should (I'm assuming) allow bi-directional > communications? So somewhere before your drop/reject rules, have: > > -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT Yes, you need to allow established connections to return back through the firewall, otherwise you will never receive your replies back. I think the source vs destination discussion is really being caused by the definition of "inbound" vs "outbound" rule definitions. In either case you will want a destination requirement but the way you think about the connection is different. The Established/Related rule is mandatory in allowing outbound connections to return back through the firewall. > It works for me. > > -- > S C Rigler > RHCE #803003335409754 -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
