From owner-freebsd-questions@FreeBSD.ORG Thu Jan 20 04:07:57 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA07D16A4CE for ; Thu, 20 Jan 2005 04:07:57 +0000 (GMT) Received: from nuumen.pair.com (nuumen.pair.com [209.68.1.119]) by mx1.FreeBSD.org (Postfix) with SMTP id 64A7A43D2D for ; Thu, 20 Jan 2005 04:07:57 +0000 (GMT) (envelope-from thuppi@nuumen.pair.com) Received: (qmail 41076 invoked by uid 55300); 20 Jan 2005 04:07:56 -0000 Date: Wed, 19 Jan 2005 23:07:56 -0500 (EST) From: Tom Huppi X-X-Sender: thuppi@nuumen.pair.com To: Erik Norgaard In-Reply-To: <41EED7C2.10700@locolomo.org> Message-ID: References: <41EED7C2.10700@locolomo.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-questions@freebsd.org Subject: Re: NAT/DNS question/recommendation? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2005 04:07:58 -0000 On Wed, 19 Jan 2005, Erik Norgaard wrote: Tom Huppi wrote: > So, what do you use for firewall/nat? ipfw/ipf/pf? I think I can > help you with ipf, if you use something else then I'm sure > someone can help you once they know they have the knowledge you > need. user-ppp has it's own firewall implementation which is separate from the above three mentioned. That's what I'm using. I'd have to use it anyway to get dial-bound rules, and its other capabilities are sufficient for my basic needs: ... # And outgoing icmp set filter out 14 permit 0 0 icmp ... # And the remote host can ping the local gateway (only) set filter in 10 permit 0/0 MYADDR icmp src eq 8 ... that sort of thing. > While your filter rules might be long, the nat rules should be quite > simple, and typically it's nat that causes problems, so please post that. You'r right. They are extreamly simple: nat enable yes (in ppp.conf) There is also an 'enable dns' entry which I may play around with some more. In fact, I'll have to if I...see last para... > >>ssh delays? did you try to type in the ip to see if it was faster? > > > > Yup. No change. I should have mentioned that for sure. > > This is really important because this suggests that there is no problem > with your resolv.conf or other named configuration files. I'm not using named...yet.... > >>I think I get the picture of your network but sometimes it helps a lot > >>if you scetch the network with a ascii-diagram, add ip's etc. > > > > > > - 172...20 > > ip-by-ppp | - 172...8 > > | | | > > net <-> gw <-> srvr > > | | | > > info, u-ppp, dfrtr:isp's dns server > > porn, w/fw /etc/hosts: ....8 srvr.made-up-dom srvr > > trash, w/nat. ...20 gw.made-up-dom gw > > etc. defrt set /e/nsswitch.conf: files dns > > by uppp. > > no ipv6 ipv6 (and 4) > > Ah, I see, dfrtr is default router? It shouldn't be the isp but the > internal ip of your gw. Otherwise you might get some strange behaviour > (which you seem to have). Typo in the diagram. 'srvr's defaultrouter is ...20, and it's resolv.conf specifies my ISP's nameserver. My now long gone text was more accurate. > > I just realized that I am setting 'defaultdomain' in the server's > > /etc/rc.conf in spite of the fact that I'm not currently running > > NIS in my local network. I'll try getting rid of that to see if > > it helps. > > Note that nis domain and dns domain is _not_ the same. Setting your > default domain in rc.conf sets the nis default domain, and has > absolutely nothing to do with dns. Yes and possibly no. I believe that it can have an influence on how the system tries to resolve hostsnames (since Sun wanted like hell for people to use NIS for this purpose decades ago before security was a consideration...), but I doubt that it's the problem here. In fact, I can now say that it isn't. (nsswitch.conf man on some systems mentions this...dunno if the capability even exists on xBSD systems.) > > BTW, here's the salient part of a tcpdump on the tun0 interface > > when I ssh from 'gw' to 'srvr': > > > > 10:32:36.698042 IP gila.62914 > king.dialoregon.net.domain: > > 63948+ PTR? 20.0.16.172.in-addr.arpa. (42) > > 10:32:36.990638 IP king.dialoregon.net.domain > gila.62914: > > 63948 NXDomain 0/1/0 (119) > > Ok, sorry, I'm used to snort output, but good idea, try sniff and dump > so you can see what happens in slow. What happens is, 'gila' (aka 'srvr') tries to do a reverse dns lookup and hangs until it times out or until it gets back a reply. 'non-existant domain' in this case. The funny thing is that once it gets even _this_ response it happily proceeds. I don't know what it _would_ be unhappy about...it makes the whole test seem rather pointless in addition to being frustrating from my standpoint. The interesting thing is, as I mentioned, when PPP is completely shut down the 'srvr' doesn't seem to even try this reverse DNS lookup silliness (or else maybe it just fails miserably and silently right away.) That makes me think that maybe there is some method of inducing PPP to lie to it's clients (for lack of a better term) about it's status when it is active but not on-line. > > So 'srvr' is looking up 'gw's IP when it _thinks_ there is access > > to a DNS server. That's what I thought. Question is, 'how to > > make it stop?' > > > > > Here's my /etc/hosts: > > ------- > > ::1 localhost localhost.huppih.com > > 127.0.0.1 localhost localhost.huppih.com > > > > 172.16.0.8 gila.huppih.com gila 172.16.0.20 agama.huppih.com agama > > Typo or copy/paste error? One ip per line. In the above 172.16.0.20 > becomes an alias for 172.16.0.8 (if it makes sense at all). Yup, another typo...this time form re-formatting paragraphs. > > Just knowing that someone has a similar setup and it works would > > be of significant help since it would tell me if there even is a > > solution. Else, and also very good would be to know that it's an > > intractable problem with the tools I use. > > I think that when you get to that point it's time to start clean and be > systematic. Remove anything that might blur the picture, unneeded > services and stuff. I think it's time to declare things semi-broken and unlikely to be fixed since most developers don't live in third-world countries where the infrastructure is so poor that dial-up connectivity is all that is available. Alas, I live in such a country (the USA.) If it is true that gethostbyaddr() and it's ilk ignore local configurations the fix might not be very easy anyway. I'll just set up a DNS server on my gateway so my poor (stupid) server can get a proper reverse DNS lookup when it feels the urge. I could have done 10 of them in the time it has taken to research this problem. BTW, I found that I can quell this lookup via a setting in sshd.conf, but I still have mountd and God knows what else to piss around with if I continue this course of solution. Thanks for your help, -Tom