Date: Sun, 10 Dec 2000 21:44:40 -0500 From: Robert Kosinski <whelkman@operamail.com> To: Nick Rogness <nick@rapidnet.com>, Robert Kosinski <whelkman@operamail.com> Cc: freebsd-net <freebsd-net@freebsd.org> Subject: RE: Odd TCP / DNS behavior in 4.x Message-ID: <3A34C1E7@operamail.com>
next in thread | raw e-mail | index | archive | help
It seems no one has any idea of a solution to my problem. In that case, can anyone recommend a thorough network guide that systematically runs through the entire process of basic networking? I have tried all sorts of things, and I cannot resolve this problem. At this point I am willing to try anything. I really enjoy FreeBSD, but I cannot use it if it will not function correctly. I'd prefer not to switch to another OS, but this problem is holding back my plans. Any suggestions at all would be appreciated. Thanks again, all. >===== Original Message From Robert Kosinski <whelkman@operamail.com> ===== >Thank you for your prompt reply, Mr. Rogness. > >> Did you try running on different hardware? > >No, but I do not see how the outgoing device can be at fault. >The outgoing device is a US Robotics 56K Voice/Fax modem (yuck, >I know). It has given me flawless operation under several >operating systems and even appears to function normally under >FreeBSD. As I said, there are no problems NAT-ting through the >box, just using the FreeBSD machine itself. The only hardware >I have to swap in place of it is another USR 56k modem. > >> Any unusual syslog entries? > >There aren't any normal syslog entries at all, but if I browse >through Squid, I receive the following log entries in access.log >several minutes after attempting to access the site: > >975964740.216 240966 192.168.0.2 TCP_MISS/504 1039 GET >http://litestep.org/ - DIRECT/litestep.org - > >Of course, I have attempted to connect to litestep.org (which is >just a redirect to litestep.net which does not work, either). > >975965019.609 241570 192.168.0.2 TCP_MISS/504 1041 GET >http://209.116.0.210/ - DIRECT/209.116.0.210 - > >I resolved litestep.org to its IP, 209.116.0.210, and attempted to >connect to that. litestep.org, www.litestep.org, litestep.net, and >www.litestep.net all share the same IP. > >A 504 is a gateway timeout, I know, but that's about all I can say >regarding it. Just to refresh, by turning off Squid (which resides >on the FreeBSD box) and connecting to a site without it from a >machine behind the firewall (i.e. using packet forwarding), the site >will load correctly. > >> Are you running bind? > >No. > >> Rule #100 and #200 never get used in the above ruleset. Move them >> to before the natd statement. > >I was wondering about that. I didn't think there was a chance they >would get used, either. Truth is, I just ripped that off of FreeBSD >Diary and never paid attention to the rules since those and the >FreeBSD shipped "open" ruleset function the same as far as connections >from the physical FreeBSD machine are concerned. > >> If you are going to use rule numbers use rule numbers on every rule. >> Makes it easier to understand (IMO). > >I agree. Whenever I get around to writing my own firewall, I will place >numbers before each rule, but that firewall isn't mine. > >> What is the output of `ipfw -a l' ? > >After moving 100 and 200 above the natd statement per your suggestion, >the output is: > >00100 0 0 allow ip from any to any via lo0 >00200 0 0 deny ip from any to 127.0.0.0/8 >00300 20 1767 divert 8668 ip from any to any via tun0 >00400 274 15868 allow ip from any to any >65535 4 237 deny ip from any to any > >> Turn off deny_incoming while testing. > >Done. > >Well, that's about all I can say for now. Thank you very much for your reply. >I appreciate it. >===== Original Message From Nick Rogness <nick@rapidnet.com> ===== >On Mon, 4 Dec 2000, Robert Kosinski wrote: > > Hard to say what it is. Did you try running on different > hardware? Any unusual syslog entries? More comments below. > > >> I am using FreeBSD 4.2-STABLE (CTM 4.0342), but this problem has persisted >> throughout several upgrades of the machine. This box is used as a packet >> filtering firewall with network address translation for a small, private >> class-C >> network (192.168.0.0/24). Besides a minor problem with ICQ logging off about >> every ten minutes and then coming back on, all machines behind the firewall >> have >> as normal TCP, UDP, etc. access as you could expect from NAT. >> >> The problem is: TCP access on the actual FreeBSD machine is flaky at best. >> For >> some reason, I can only connect to about 50% of all sites I have attempted. >> This problem affects FTP (and the ports collection), HTTP (and the Squid >> proxy), >> and probably all TCP-based traffic. The same 50% of the sites I cannot access >> remain constant. ICMP (ping and traceroute) seems not affected. >> >> What appears to happen on the "dead" sites is a DNS lookup and an eventual >> timeout. The same DNS servers are used by the FreeBSD machine as well as >> machines behind the firewall, so I do not believe I am a victim of defective >> DNS >> servers. > > Are you running bind? If so, your /etc/resolv.conf file should > look someting like: > > domain domainname.com > nameserver 127.0.0.1 > > You should be querying your local nameserver before going out to > ask others. Do you have forwarders configured? > > >Manually resolving the IPs of affected sites and attempting to >> connect >> to the IP results in failure as well. >> >> I know this is not a problem with the NAT configuration because I have shut >> off >> NAT completely and used the FreeBSD machine as a regular client. Of course >> the >> problem persists. >> >> I have to load at least a minimal IPFW rule set since the machine's ports are >> closed by default. For now, I am using a minor variation of the "open" rule >> set >> from FreeBSD's default rc.firewall. Neither the original rc.firewall rule set >> nor the set I'm using result in proper communication from the physical FreeBSD >> machine. >> >> For record, the IPFW rule set is >> >> /sbin/ipfw -f flush >> /sbin/ipfw add divert natd all from any to any via tun0 >> /sbin/ipfw add pass all from any to any >> /sbin/ipfw add 100 pass all from any to any via lo0 >> /sbin/ipfw add 200 deny all from any to 127.0.0.0/8 >> > > What is the output of `ipfw -a l' ? If you are going to use > rule numbers use rule numbers on every rule. Makes it easier to > understand (IMO). Rule #100 and #200 never get used in the above > ruleset. Move them to before the natd statement. > >> and the natd rule set is >> >> log no >> deny_incoming no >> same_ports yes >> dynamic yes >> verbose no >> interface tun0 >> redirect_port tcp 192.168.0.2:2000-2020 2000-2020 >> > > Turn off deny_incoming while testing. > >Nick Rogness >- Drive defensively. Buy a tank. 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?3A34C1E7>