Re: [leaf-user] Blocking established connections from external port 53's
On Thu, 13 Jun 2002 23:25:14 -0500 Michael D. Schleif [EMAIL PROTECTED] wrote: [ snip ] Let's slow down and look at this carefully. I assume that 24.118.176.137 is your external address -- right? Correct. [ snip ] Now, if you were using only attbi's dns servers that they assigned to you, there is no reason that your system would be contacting them for dns. From memory, when we used to have the old one way cable modem (dial in with phone, receive data thru cable modem) we were assigned a dns IP number. However, since they upgraded us to a two way cable modem, they do not supply a dns IP. On ATT's web site, they actually state to disable DNS for windows 9x users. dnscache shouldn't interfer with that should it? Therefore, it is reasonable to assume that your system is mis-configured for dns. Are you using dnscache? tinydns? bind? dnscache only. However I do not recall ever doing any configuration for that. I am using basic Dachstein with the following packages; root4.0.6 etc 4.0.1 ramlog 1.1 local 4.0.6 modules 4.0.6 dhclient2.0pl5 dhcpd 2.0pl5 dnscache1.05a weblet 1.2.0 psentry 1.0 libz sshd3.0p1 ssh 3.0p1 The fact that you say that these connections are only a subset of an overwhelming number of identical connections indicates a serious configuration problem on your gateway box. I do not know enough to say I know for sure, but I believe the configuration problem lies in ATTBI's area. See, when I have these unable to connect to the net problems, so does everyone else in my neighborhood, it has been documented - plus I know of some people with slightly different IP numbers than mine that are ATT customers and they have connection problems at the same time I do. All I do, is check weblet out to see what is going on, and thats the only thing I find out of the ordinary is multiple established connections to my router, to external port 53 domain servers. Guitarlynn sent me this info; By default Dachstein has: ## UDP Services open to outside world # Space seperated list: srcip/mask_dstport # NOTE: bootpc port is used for dhcp client EXTERN_UDP_PORTS=0/0_domain 0/0_bootpc Remove the 0/0_domain entry, but leave the 0/0_bootpc if you are using DHCP to connect to your ISP. I have had this problem once or twice other DNS servers are trying to connect to your DNS server on the router (dnscache, tinydns, bind, whatever). I've never had it choke out a router, but dropping the open port will stop them. I did just that, and so far so good. Even the net seems to be a tad faster now. Do you know _why_ your system might be contacting these root domain servers? What do you think? Not too sure what is going on. Just seems odd that when our ability to connect to the web is shot, everybody elses seems to be also. Can't imagine my lil ole LRP router is bringing down the Internet in the Minneapolis area! Thanks for your help again Michael ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink 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
Re: [leaf-user] Blocking established connections from external port 53's
On Thursday 13 June 2002 22:34, Steve Jeppesen wrote: It seems there should be a way to modify network.conf (Dachstein CD V1.02) to not allow any external connections from any IP using port 53 - is there something in network.conf that would work? I have looked thru network.conf but do not see anything that might help block external connections to eth0 By default Dachstein has: ## UDP Services open to outside world # Space seperated list: srcip/mask_dstport # NOTE: bootpc port is used for dhcp client EXTERN_UDP_PORTS=0/0_domain 0/0_bootpc Remove the 0/0_domain entry, but leave the 0/0_bootpc if you are using DHCP to connect to your ISP. I have had this problem once or twice other DNS servers are trying to connect to your DNS server on the router (dnscache, tinydns, bind, whatever). I've never had it choke out a router, but dropping the open port will stop them. I hope this helps, -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink 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
Re: [leaf-user] Blocking established connections from external port 53's
Steve Jeppesen wrote: [ snip ] Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 192.168.1.254:80192.168.1.2:33449 ESTABLISHED tcp0 0 192.168.1.254:80192.168.1.2:33447 TIME_WAIT tcp0 0 192.168.1.254:80192.168.1.2:33446 TIME_WAIT tcp0 0 192.168.1.254:80192.168.1.2:33444 TIME_WAIT udp0 0 24.118.176.137:52220192.203.230.10:53 ESTABLISHED udp0 0 24.118.176.137:43084128.8.10.90:53 ESTABLISHED udp0 0 24.118.176.137:21690128.63.2.53:53 ESTABLISHED udp0 0 24.118.176.137:34665128.8.10.90:53 ESTABLISHED udp0 0 24.118.176.137:30698192.33.4.12:53 ESTABLISHED udp0 0 24.118.176.137:31418198.32.64.12:53 ESTABLISHED udp0 0 24.118.176.137:40885198.41.0.4:53 ESTABLISHED udp0 0 24.118.176.137:22397198.41.0.10:53 ESTABLISHED udp0 0 24.118.176.137:48569192.36.148.17:53ESTABLISHED udp0 0 24.118.176.137:18114193.0.14.129:53 ESTABLISHED udp0 0 24.118.176.137:39686128.63.2.53:53 ESTABLISHED udp0 0 24.118.176.137:53853128.8.10.90:53 ESTABLISHED udp0 0 24.118.176.137:55249198.41.0.10:53 ESTABLISHED udp0 0 24.118.176.137:35631198.32.64.12:53 ESTABLISHED udp0 0 24.118.176.137:24105202.12.27.33:53 ESTABLISHED udp0 0 24.118.176.137:13567193.0.14.129:53 ESTABLISHED udp0 0 24.118.176.137:19059192.5.5.241:53 ESTABLISHED udp0 0 24.118.176.137:13893193.0.14.129:53 ESTABLISHED [ snip ] Let's slow down and look at this carefully. I assume that 24.118.176.137 is your external address -- right? Your external address is connecting to those foreign addresses on udp port 53. udp port 53 is domain, aka dns. Interestingly enough, these are the root dns servers: 128.8.10.90 128.63.2.53 128.9.0.107 192.5.5.241 192.33.4.12 192.36.148.17 192.112.36.4 192.203.230.10 193.0.14.129 198.32.64.12 198.41.0.4 198.41.0.10 202.12.27.33 These are those you listed, sorted and without duplicates: 128.8.10.90 128.63.2.53 192.5.5.241 192.33.4.12 192.36.148.17 192.203.230.10 193.0.14.129 198.32.64.12 198.41.0.4 198.41.0.10 202.12.27.33 Now, if you were using only attbi's dns servers that they assigned to you, there is no reason that your system would be contacting them for dns. Therefore, it is reasonable to assume that your system is mis-configured for dns. Are you using dnscache? tinydns? bind? The fact that you say that these connections are only a subset of an overwhelming number of identical connections indicates a serious configuration problem on your gateway box. Do you know _why_ your system might be contacting these root domain servers? What do you think? -- Best Regards, mds mds resource 888.250.3987 Dare to fix things before they break . . . Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink 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
Re: [leaf-user] Blocking established connections from external port 53's
The basic question you need to answer for us is: how is your system doing DNS? Are you running your own DNS server on the router and using it to do DNS directly (i.e., starting at the roo servers and working down)? Are you running a DNS server that uses your ISP's DNS server(s) as forwarder(s)? Are the clients on your LAN using the ISP's DNS servers directly? Something else? As a general matter, if you want to be able to access the Internet using FQNs (and not just IP addresses directly, something nobody does), you need to allow *some* UDP traffic from port 53 in. Otherwise, off-LAN DNS servers will be unable to respond to the queries you send them ... and while I don't know from what you sent *how* you do (off-site) DNS queries, you must be doing them *somehow*. It would not surprise me if the current connections you list below were incomplete DNS queries. If so, the reason no one on the homenetwork can connect to the Internet may be that you have an undiagnosed DNS problem, so URLs (or FQNs for whatever services you mean by connect) do not resolve. The mere existence of open connections should not prevent LAN users from accessing the Internet (at least not in in the quantities you report ... you are in no danger of running out of ports). You might want to report with a more descriptive trouble report. The SR FAQ link below will help you do so, if you care to try this approach. (I don't recall your prior postings, but if you really got no responses, it may be that they were too vague to elicit anything useful. There are enough of us regulars, with a wide range of expertises and tempraments, that it is rare that no one responds to a query.) At 10:34 PM 6/13/02 -0500, Steve Jeppesen wrote: I am having trouble with these established connections showing up in my viewmasq log to the point where no one on the homenetwork can connect to the Internet. The problem seemed to go away after AT$T assigned new IP's for everyone in the neighborhood, but just today it reared its ugly head again. I have asked for help before from the list here, but nobody replied to my posts. Please tell me at least is it something I am being ignorant about and not researching the problem enough myself before posting here? Or is it that nobody here knows what to do about it? It seems there should be a way to modify network.conf (Dachstein CD V1.02) to not allow any external connections from any IP using port 53 - is there something in network.conf that would work? I have looked thru network.conf but do not see anything that might help block external connections to eth0 Here is a small portion of my Current connections as reported in viewmasq; Active Internet connections (w/o servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 192.168.1.254:80192.168.1.2:33449 ESTABLISHED tcp0 0 192.168.1.254:80192.168.1.2:33447 TIME_WAIT tcp0 0 192.168.1.254:80192.168.1.2:33446 TIME_WAIT tcp0 0 192.168.1.254:80192.168.1.2:33444 TIME_WAIT udp0 0 24.118.176.137:52220192.203.230.10:53 ESTABLISHED udp0 0 24.118.176.137:43084128.8.10.90:53 ESTABLISHED udp0 0 24.118.176.137:21690128.63.2.53:53 ESTABLISHED udp0 0 24.118.176.137:34665128.8.10.90:53 ESTABLISHED udp0 0 24.118.176.137:30698192.33.4.12:53 ESTABLISHED udp0 0 24.118.176.137:31418198.32.64.12:53 ESTABLISHED udp0 0 24.118.176.137:40885198.41.0.4:53 ESTABLISHED udp0 0 24.118.176.137:22397198.41.0.10:53 ESTABLISHED udp0 0 24.118.176.137:48569192.36.148.17:53ESTABLISHED udp0 0 24.118.176.137:18114193.0.14.129:53 ESTABLISHED udp0 0 24.118.176.137:39686128.63.2.53:53 ESTABLISHED udp0 0 24.118.176.137:53853128.8.10.90:53 ESTABLISHED udp0 0 24.118.176.137:55249198.41.0.10:53 ESTABLISHED udp0 0 24.118.176.137:35631198.32.64.12:53 ESTABLISHED udp0 0 24.118.176.137:24105202.12.27.33:53 ESTABLISHED udp0 0 24.118.176.137:13567193.0.14.129:53 ESTABLISHED udp0 0 24.118.176.137:19059192.5.5.241:53 ESTABLISHED udp0 0 24.118.176.137:13893193.0.14.129:53 ESTABLISHED Notice the Foreign Address column... How can I block those xxx.xxx.xxx.xxx:53 using Dachstein? Thanks for any help and/or replies - I am pulling my hair out over this, what hair I have left! -- ---Never tell me the odds!-- Ray Olszewski-- Han Solo Palo Alto, California, USA
