[NCLUG] IP Masqing on the New and Improved AT&T

[Eric Brunson]

* Neil Doane (caine at vasoftware.com) [011211 10:42]:
> Has anyone else noticed strange things afoot when trying to do IP Masqing
> through AT&T's new setup?   It seemed that no matter what I did, I couldn't
> get out from my Masqed boxes (the ones behind my firewall).  My Masqing box,
> on the outside, could see and do everything appropriately, but it seemed
> that even ports were being blocked when I tried to connect out from the
> backend boxes and http requests out just always returned the transition-aid
> page (http://transition-aid.attbi.com/attbi_welcome_page.html).  Called tech
> support who immediately sent me to a higher-level tech who informed me that 
> AT&T isn't "supporting networks anymore" and that, because of their recent 
> infrastructure changes, they "havn't put in place the neccessary hardware 
> to support home networks."  Well, this sounded like bullshit, of course; 
> NAT is designed to be transparent...you don't need to _do_ anything to make 
> it work.  It seemed like they were up to something fishy.  A little more 
> digging and I started to realize that somehow, their DNS servers have been 
> set up to selectively return replys only to the primary host on the network, 
> if anything else asks for a resolution, even if the request datagrams are 
> source ip/port re-written to _appear_ to come from the primary dhcp host, 
> it gets denied an accurate answer and instead is given the IP for 
> transition-aid.attbi.com apparently.  

When my cable connectivity came back up about a week ago (I'm in
Denver) they were intercepting port 80 and redirecting to their
website, but other than that all my NATting was working perfectly.
Their resolvers worked fine for my NATed boxes and still are and I
just checked and they are no longer redirecting port 80.

I don't know that you *can* reliably identify a NATed packet, can
someone tell me if I'm wrong?

> I'm not really as intimate with DNS setup as I'd like, and I suspect that
> their DNS may be using the source MAC addy to make the distinction, but I'd
> love to hear ideas about how this is set up from someone with more specific
> DNS knowledge.  It sounds to me like they went _out of their way_ to create
> a setup that would not allow ip-forwarding home networks to function
> properly, possibly to create a need for a their upcoming 'improved service
> options'?   If so, that's some serious dicketry.

Even in a not NAT environment you can only see the MAC address of an
interface if you're on the same rail.  Once that packet passes through
a router the MAC address of the originating interface is not only
unavailable, but fairly useless.  Remember that the MAC address is
part of the ethernet frame, not the IP packet, NATed packets have the
MAC address of the NATting box.

> I managed to get around the whole mess by simply removing
> all the AT&T nameservers from the resolv.confs of my backend workstations
> and pointing them all to my internal nameserver, which runs on my IP 
> Masqing box and so can get valid replys from the AT&T DNS servers.

I'm sorry I don't have an solution for your problems and I certainly
don't deny that you are seeing this behavior, but from my (possibly
incorrect) understanding of how NATting works, I can't agree with your
proposed expanation for it.

e.

-- 
 Eric Brunson   brunson at level3.net   page-eric at level3.net  
tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY