Masking Public IPs -- feature or limitation? OS 6.3 vs 7.0 1

[bobjunga]

We have a PIX 515e (OS6.3) with outside,dmz and inside interfaces. Public IPs are static NAT'd to private adrresses in the dmz.

From inside our network we have to use the private IPs of the DMZ computers, instead of the public IPs that the rest of the world sees. I understand that this is a common situation.

Question 1: Is this a feature that protects us from some vunerability or is it simply a limitation of the PIX 515e?

Question 2: If we upgrade to PIX OS 7.0 can we 'fix' this so that we can refer to the public IP of our servers from inside and outside our network?

Thanks,

--BobG

 

[LloydSev]

first.. the computers are on a private network, so they require the use of private IPs.. you then static these systems to the OUTSIDE interface with public IPs so that the public can access them..

the reason you can not use the public IPs on the inside interface is because it is only staticly assigned to the OUTSIDE interface.

If you have a DNS server, you can just use that to add an A record for the server which points to the private IP address using the public NAME.

Computer/Network Technician
CCNA

 

[baddos]

The PIX 6.3 and 7.0 doesn't require you to NAT your DMZ w/ private IP > Public IP. That's just a best practice.

 

[bobjunga]

I know about the DNS splitting solution and I want to avoid it. We will chnage our DMZ to use our public class as a last resort.

>> the reason ... only staticly assigned to the
>> OUTSIDE interface.

So can we also repeat our static NATs assigning them to the inside interface (in addition to the outside insterface)? If so why isn't this common practice instead of the DNS hack. Is there someonething wrong with doing this?

The reason I thought that PIX OS 7 might 'solve' this for us is that it supports 'hairpinning' VPN spokes. This seems like a similar issue to me. A packet gets initially delivered to an interface only to find because of a NAT or VNP unpacking that it really needs to be rerouted through another interface.

--BobG

 

[LloydSev]

the DNS solution is not a hack in any sense of the word.

In fact, best practice is to use the DNS server to do this operation, instead of creating a more complicated PIX setup.

Computer/Network Technician
CCNA

 

[LloydSev]

To further elaborate...

DNS servers are designed specifically to store destinations for translated internet name addresses.

Instead of taking the hard route and hard coding your PIX to handle this, the best approach would be to use the software you are already using that is specifically designed to handle the need you have.

Computer/Network Technician
CCNA

 

[bobjunga]

I don't like the split DNS approach because of 1) the complication to DNS (I do not know of a feature in bind 9 to make this easy -- it seems to require having a set of inside name servers with one set of data and another public set) and 2) not all applications nessesarily use domain names instead of IPs. And how does this work with ssl certificates? Aren't they bound to a specific IP?

Anyway, I am not trying to convince you its bad. I am just trying to make the case that its not unreasonable for me to question whether its neccessary. I still wonder if there is a specific security reason not to allow traffic from inside your own network to access your public resources through their public address.

Is this common to all firewalls or is it unique to the PIX?

I still would like to know if its possible to access the DMZ from the inside by its NAT'd public addresses. (maybe by specifically providing two sets of NAT statments one bound to the the outside interface adn one to the inside interface).

Thanks for discussing this with me. I appreciate it.

--BobG

 

[ChrisAC]

The reason that you can't use the external IP addresses is because the external IP range is configured on the external interface and NATing all inbound connection. So, from a host on the inside trying to reach an external address served by the Pix, it would have to route out to the external interface and then back in the same interface, which it can't do.

If the DNS server for the domain name is located externally then using the 'alias' command ensures that the box can be reached via the domain name as the Pix 'doctors' the DNS response and replaces the answer with the internal IP address and so this is transparent to the end user.

If DNS is hosted internally then split DNS is the best answer. It's easy to set up on BIND and the only real pain is manageing two zone files for each domain. But in practice, how often is your server address likely to change?

As for SSL certificates, they should work using either public for private addresses. I can can connect to our firewalls that use SSL certificates on either the public or private address and both work just fine. This is really something that you would have to try for yourself.

Pix 7.0 might change the way that routing works and allow the use of the public IP's from the internal net but it's not something that I've looked into. As for 6.3 and below, it just doesn't work!

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************

 

[bobjunga]

So is this situation pecular to the PIX, or is it common to all firewalls? I am still trying to get a sense of whether this is by design, or an unfortunate side effect of the PIX. Put another way, is this setup the best practice for all firewalls or just the PIX?

Chris, your description of why it can't route our NAT'sd public IP traffic from the inside interface seems to be the same reasing that PIX's running 6.3 could not route between VPN spokes an why we can access the DMZ from a VNP connection in the inside interface. My understanding is that all these situations require hairpinning which, I believe, is when a packet is initially routed to an interface only to find that it has to be rerouted somewhere else.

The feature list of the PIX OS 7 says that it can now route between VPN spokes, so I am hoping that it can also handle the other two situations. Of course even if it is the same issue, there's no garantee that it will possible to configure it to behaive that way in the two situations that I am interested.

We have the memory ordered to upgrade our PIX 515e. After we upgrade I will try to rememeber to come back and report whether it works.

--BobG

 

[ChrisAC]

Bob,

This isn't common on all firewalls. As an example, I work with Firewall-1 on the Nokia platform and that allows 'routing on a stick'. I think that this is more because the Nokia's are really routers with a firewall installed on them where as the Pix is a dedicated firewall platform and is most definately not a router. I have worked with other firewalls that did allow this as well but again, they were mostly software based on a platform that could be set up as a router.

I think that Cisco have realised that they are lagging behind other products with the VPN routing issues. It's certainly a weakness of the product and dosn't allow for real VPN scalability but maybe with version 7.0 they will start to catch up again. If this works then please do let us know.

Chris.

**********************
Chris A.C, CCNA, CCSA
**********************