Date: Mon, 4 Dec 2000 09:03:45 -0700 (MST) From: Nick Rogness <nick@rapidnet.com> To: Robert Kosinski <whelkman@operamail.com> Cc: freebsd-net@freebsd.org Subject: Re: Odd TCP / DNS behavior in 4.x Message-ID: <Pine.BSF.4.21.0012040852340.94996-100000@rapidnet.com> In-Reply-To: <3A2B9094@operamail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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?Pine.BSF.4.21.0012040852340.94996-100000>