At 12:05 PM -0600 9/26/03, Kevin Benton wrote:
>1918 = RFC1918 addresses or private address spaces; in your case, 10/8.
>Since your servers are all on the 10/8 network, you're going to have to
>exclude the internal NAT IP's the PIX is using.
>Here's what's happening. Customer (outside) sends request to your DNS
>server's advertised public address. The PIX receives it on the public
>address advertised for the DNS server(s), then re-issues it on to your
>DNS box as if it were the one making the request. Why is that? If the
>PIX didn't appear to be issuing the request, the DNS server would try to
>respond directly back to the customer, releasing an untranslated address
>on out the net at worst, or at best not being able to talk to the
>customer's computer because of a lack of a route to get back to it.
>Because the address the PIX is using to talk to your DNS server is a 10
>address, it's going to match your internal list.
>
>So, what I would do is make sure that your PIX is using a pool of
>internal addresses that's dedicated just to the PIX that are restricted
>so that they're all limited to a single subnet, then add that subnet to
>your match list as an exclude (!10.128/16).
>
>--
>Kevin Benton <kevinb@xxxxxxxxxxxxx>
I didn't think that was how NAT worked on a packet filtering
firewall (a la Cisco PIX, or ipfw2+natd on say, FreeBSD). The PIX
maintains a list of static and dynamic translations, and when a
packet comes inbound on the dirty interface it checks it's static
mapping table to see where the public address (134.173.108.1 for
example) should be mapped to a private address (10.2.2.1), then sends
the packet out on the clean interface with the same source address,
but a new destination. The internal computer is unaware of the PIX
even being in the way. The DNS server then sends out its response to
the requesting server (say, 4.2.2.2), and the PIX intercepts it, maps
it to the right connection in its NAT table, and rewrites the source
address.
Outbound connections are similar, only the PIX uses a pool of
NAT/PAT addresses instead of static mappings for computers w/o a
static external address. Otherwise, our access logs would be filled
with useless entries for say, HTTP requests from the PIX instead of
from the actual requester. So while all traffic on our network hits
that PIX (Hello single point of failure) if it is destined for the
cloud, none of our internal computers are away of the PIX's existence.
Proof of concept can be had from my access log entry,
Sep 26 10:34:53 CHS.CUSD.Claremont.Edu named[12653]: [ID 866145
daemon.info] client 156.3.1.3#53: query: Windy.CUSD.claremont.edu IN A
Where 156.3.1.3 is not on any network I control, as it
resolves to netmgr.lacoe.edu. The same can be seen on our Apache and
sendmail logs.
The xlate table in the PIX also has more convincing evidence
of this, however I cannot access the PIX directly from my
workstation, and such can't show you it, however they say essentially
that address A is address B and expires in C minutes.
Kelly
--
Kelly Kane
Claremont Unified School District
|
