Cisco PIX 501: Can't ping global IP-Adress from NATed IP

You can't do it without extra hardware.

Thanks for your answer Walter Roberson,

but how am I supposed to secure the following setup then?

I've got a whole /28 subnet(let's assume x.x.x.0-x.x.x.15). The next hop and default route is x.x.x.1 and x.x.x.15 is the broadcast address for this net.

My task is to put more nodes into that range than the remaining 13IPs would allow me to do. So I have to use some kind of NAT. Also, there are some servers which have to be accessable from other nets and from "my subnet". Finally, everythink should be secured by the PIX-firewall.

I thought I should try it like most guides advised to: NATing (one-to-one translation) for the servers, one IP for NAT/PAT and the remaining IPs for NATing the clients.

The clients and servers however should be able to communicate via the global ip (e.g. x.x.x.2) which doesn't work.

How can I achieve that? Any solutions are welcome...

Am 04.05.2006, 19:39 Uhr, schrieb Walter Roberson :

If that was your requirement, then you chose the wrong product. The PIX 501 cannot do that by itself, and possibly will never be able to do that... and I and others have mentioned that many times in this newsgroup.

Any other model of PIX or ASA that is currently on sale would be able to handle the situation [presuming 6.3(2) or later software] (though the 506e would require the assistance of a vlan-aware switch.)

You must either add hardware, change hardware, or give up the requirement that internal hosts must be able to access the servers by the external IP address instead of by the host name.

You indicated that adding DNS to the mix was not an option. That significantly constrains your software-based solutions.

It would help if you were to explain -why- DNS is not an option, and why internal clients must be able to access the servers via the public IP *address* rather than the hostname.

Am 04.05.2006, 23:53 Uhr, schrieb Walter Roberson :

I finally got that in writing ;)

Sorry, I am rather new to this newsgroup. And it seems I didn't prepare well.

Ok, what hardware should be added in order to be able to acomplish the scenario?

Well there already is a DNS on that network, will that be sufficient? Will the PIX be able to translate the lookup-requests then and substitute the external for the internal adress? (that "alias"-thing, right?) To my mind, the DNS resolves the request to the external IP. Therefore, the client will again try to communicate with that address and the PIX would still not able to translate that IP to the internal IP. In my understanding, another DNS server at the PIX's inside could solve that issue. Am I right?

The reason why I didn't want to set up an DNS is my lack of experience with such services and it seems that some costume software we use simply isn't using the gethostbyname() function and is therefor doomed to use IPs. Also the whole setup already did work without a firewall and fewer nodes (it comes down to just plugging in the nodes, setting the default gateway). My task is to put that PIX infront of the nodes. The first thing I learned back then was: it is not possible to force the PIX to behave in a transparent way (e.g. just filter and foreward the traffic for x.x.x.0-x.x.x.15 - without NAT), or did I configure something wrong?

Thanks for your patience Walter Roberson!

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.

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.]

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. This is often done by arranging a "carrier network" with your ISP -- a distinct /30 or /29 network that is there just to allow your WAN equipment to talk to the ISP so that the ISP can route the main network to you.

Am 05.05.2006, 11:41 Uhr, schrieb Walter Roberson :

So there is no need for that alias-command?!

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?!

Ok, I understood that. Leaves the question open why the PIX forces this behaviour. Maybe for security reasons...

So far, thanks a lot for your answers and time, Walter Roberson!

The alias command is deprecated, and not supported by PDM, and is gone in 7.x.

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.

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.

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.

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 :

Yes, I am with you. Seems resonable and I don't know why that did not get to my mind in the first place.

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!