Subject: Re: failure from bizarre NAT setup
To: Wolfgang S. Rupprecht <wolfgang+gnus20040422T090722@dailyplanet.dontspam.wsrcc.com>
From: Steven M. Bellovin <smb@research.att.com>
List: tech-net
Date: 04/22/2004 12:49:02
In message <x74qrcgeq3.fsf@bonnet.wsrcc.com>, "Wolfgang S. Rupprecht" writes:
>
>smb@research.att.com (Steve Bellovin) writes:
>>    fetchmail: gethostby*.getanswer: asked for "machshav.com IN AAAA", got ty
>pe "A"
>
>When my cablemodem ISP (athome) died a few years back and I needed a
>cheap fallback ASAP. I got a very cheap local dialup.  Big mistake.
>One thing that wasn't even close to working was their sorry excuse of
>a nameserver.  I just ran my own named (bind-9 preferably) and was
>happy.
>
>One other thing that never worked with them was that certain sites
>just couldn't be contacted when I used my normal settings.  Pings to
>them worked so it wasn't a routing problem, but normal TCP packets
>just got dead air.  It felt a bit like they were using PPPOE as their
>outgoing link and had read some idiotic "security on the internet"
>book which recommenced filtering all ICMP's.  All in all, I'm very
>glad to be rid of them.
>
>So in a nutshell, I'd try 1) runnning your own named and 2) if you
>have trouble getting to your destination lower the MTU at both ends of
>the link (if you have access).
>

I am running my own name server.  And as I said, the problem is with 
the bind() call in the applications; it's not an MTU problem.

Turns out that this hotel will let you get a public IP address for US$2/day
extra.  That's a cheap bypass...

But I don't really understand where the problem is happening.  I'm not 
convinced there's nothing that can/should be fixed in NetBSD.  It may, 
for example, be related to ssh and telnet's support for v4 and v6 
(though specifying -4 explicitly didn't help).


		--Steve Bellovin, http://www.research.att.com/~smb