Re: Cisco PIX 501: Can't ping global IP-Adress from NATed IP
- From: "Michael Schuberl" <cisco_pix@xxxxxxxx>
- Date: Mon, 08 May 2006 22:57:56 +0200
Thank you so much!
Today I searched for your name in this newsgroup.
I was really astonished: you answered me even though the same questions have been asking all the time!
I owe you one, since I got no further questions atm ;)
Am 06.05.2006, 18:17 Uhr, schrieb Walter Roberson <roberson@xxxxxxxxxxxx>:
In article <op.s84lsmcg7mx1hz@localhost>,Yes, I am with you. Seems resonable and I don't know why that did not get to my mind in the first place.
Michael Schuberl <cisco_pix@xxxxxxxx> wrote:
Am 05.05.2006, 11:41 Uhr, schrieb Walter Roberson <roberson@xxxxxxxxxxxx>:Have the internal DNS server hand out the internal address, and
on the 'static' statement for the server, add the 'dns' keyword. Then
when -external- hosts do a query, the PIX will translate the
internal IP to the external IP as the DNS response goes out of the
network.
So there is no need for that alias-command?!
The alias command is deprecated, and not supported by PDM, and
is gone in 7.x.
If the software can be configured to use the internal IPs for the
servers, then configure the DNS and static as noted above and everything
will be fine. [If the software is also used from outside your LAN,
then configure the external hosts to use the public IP.]
Ok, thanks a lot for the advise, I will try to configure the DNS as
supposed by you.
Due to the fact that I've never done anything with DNS I've got the
following (newbie?!) question:
how to tell the outside clients to use my internal DNS-server to lookup
the names, rather then the DNSserver located outside? Do I have to
configure that outside server to foreward lookups for my subnet to my
internal dns then?!
Configure the external DNS with the public IPs, and the internal
DNS with the internal IPs, and point either kind of client to either.
The 'dns' keyword on the 'static' command works both ways: if your
internal users fetch a public IP from an external DNS server then it
gets translated to the internal IP on its way in, and if your external
users fetch a private IP from the internal DNS server then it gets
translated to the external [public] IP on its way out.
The PIX 501 is fine with using the same address internally and
externally.
The catch is that the two interfaces cannot have the same IP subnet,
so the external interface must be part of a different subnet and
your WAN router must route the public range to to the IP address
of the external interface.
Ok, I understood that. Leaves the question open why the PIX forces this
behaviour. Maybe for security reasons...
No, it's a simple matter of routing. PIX in general can have
more than 2 interfaces. If your internal and external interfaces had
the same IP subnet, then if a packet came from one of the DMZ interfaces
then the PIX wouldn't know which interface to send it towards.
*note to self: improve abstract thinking*
Recall that your WAN router is going to have to be in the same subnet
as your PIX outside interface IP, and your LAN router is going to have
to be in the same subnet as your PIX inside interface IP, so if your
inside and outside IP ranges were the same, packets from the DMZ could
potentially have to go to the inside or outside for the same destination
IP subnet. In order to manage that kind of situation, you would have
to explicitly designate, IP by IP, which ones in the subnet were
internal and which were external. It's theoretically possible, yes,
and might be practical for a small number of IPs, but it is a situation
that doesn't scale at all well. Now imagine if the way that the IPs
were assigned was via an external DHCP server [since, after all,
hypothetically everything is on the same subnet, you are going to
expect to be able to DHCP into that subnet via an external server,
right?] -- you can see how ugly the management of which IP is
internal or external would become. Much easier to work based upon
subnets: those scale reasonably well in most environments.
People keep saying, "The PIX isn't a router!", but routing is
crucial to the operation of the PIX [at least up through 6.x].
Very nearly the first thing that the PIX does with a packet is to
look up the routing information and extract the destination interface.
Then it uses the source and destination interface information to check
for an active translation (or to build a new translation), and it isn't
until after that that it checks the ACLs.
You're right, during my first search for guides to the PiX, I found several articles pretending that "the PiX isn't a router". But obviously it works on OSI-layer3 and therefor has what I would call "routing features"...
Thanks for your help!
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
.
- References:
- Cisco PIX 501: Can't ping global IP-Adress from NATed IP
- From: Michael Schuberl
- Re: Cisco PIX 501: Can't ping global IP-Adress from NATed IP
- From: Michael Schuberl
- Re: Cisco PIX 501: Can't ping global IP-Adress from NATed IP
- From: Walter Roberson
- Re: Cisco PIX 501: Can't ping global IP-Adress from NATed IP
- From: Michael Schuberl
- Re: Cisco PIX 501: Can't ping global IP-Adress from NATed IP
- From: Walter Roberson
- Cisco PIX 501: Can't ping global IP-Adress from NATed IP
- Prev by Date: Re: VPN between Concentrator & Router
- Next by Date: Re: Catalyst 6000 advise
- Previous by thread: Re: Cisco PIX 501: Can't ping global IP-Adress from NATed IP
- Next by thread: CatOS BPDU guard config
- Index(es):
Relevant Pages
|
|
