Pix 501 - Allowing Routing of Public IP address

[danielwatts]

Dear All,

This one might be a little anti-intuative but I'm sure it's not uncommon enough for it to have never cropped up before.

I run a very simple network. 1 connection, 1 firewall, 2 servers on a 192.168.1.* network. Each server has a hostname say s1.host.com and s2.host.com.

I have a script that tries to connect, via ftp, from s1 to s2. This uses the hostname as the target to connect to. A DNS lookup returns the Public IP address and a connection is attempted.

The problem is that the firewall, seeing this connection to an external IP does not seem to do anything with it. This, I am told, is understandable since the point of NAT is to have two entirely separate IP spaces on either side.

However - I would like to 'break' this purism and allow such a connection to take place. The obvious solution would be in the from of a list of IP addresses on the firewall that are mapped. Eg a rule that says something like

"Route any connection to ip 64.1.2.34 from inside the firewall back to the ip 192.168.1.2 inside the firewall"

Is this at all possible? Or something like this?

============

Other things I have tried:

/etc/networks file -

entered a line eg 64.1.2.34 s1.host.com

didn't work (in fact the networks file was not present to start with and perhaps does not apply on fedora boxes?)

Internal DNS views - a huge administrative burden to maintain two DNS views as well as not solving the problem if a connection direct to the IP is required.

Many many thanks for any input.

Kind regards,

Daniel

[scoclayton]

The way we solve this dilemma is by NAT'ing the DNS response that is sent back from the DNS server. In other words, the DNS server responds with the global address. As the response passes through the PIX, the PIX changes the IP address *in* the DNS response to be the local address rather than the global address. Take a look at the following section from the command reference:

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_63/cmdref/s.htm#wp1026694

Pay attention to the 'dns' keyword.

I am pretty sure we added this feature in 6.2 code so you need to be running at least this version. Of course, 6.3(4) is recommended.

Hope this helps explain matters.

Scott

[danielwatts]

Thanks so much for the swift reply. That looks very much what I am after. Would the command be:

static (inside,outside) {public_ip_map_from} {internal_ip_map_to} dns ?

So that say domain.com resolves to public_ip_map_from. All dns lookups via the PIX will actually return internal_ip_map_to?

That sounds pretty perfect. Of course it won't allow a connection direct to the global IP but this is probably not an issue. If it were what would the fix for that be?

Thanks again Scott. So much.

Daniel

[scoclayton]

You got it. The command above should be all you need. You probably already have the static in place. You do not have to remove the current one...just re-enter it with the 'dns' option and it will over-write the entry. You will probably want to do a 'cl xlate' as well. And finally, go ahead and upgrade to 6.3(4) as there were some issues with this option in earlier codes.

Scott

[danielwatts]

Scott,

Sorry to bother you. My host has entered the following line into the PIX:

static (inside,outside) fs2 fs2web dns netmask 255.255.255.255 0 0

Unfortuantely this does not seem to have solved the problem. Before we start looking at other possible causes could you confirm that that is correct? I expect that fs2 is and alias for the public ip and fs2web is the internal ip.

Also - would this tranlsation affect the return output of "dig" statements??

Many thanks for your continued extremely helpful support.

Daniel

[scoclayton]

Yes, the command above looks correct assuming the fs2 and fs2web are correct. You can get them to send you a 'sh name' to confirm this. Also, make sure they cleared the xlate (clear xlate is the command) so that the new info can be applied to the translation. And finally, can you confirm the code running on the PIX? We had some issues with this functionality in some versions of code.

Thanks,

Scott

[danielwatts]

Scott,

You've been really really great. I'm sorry it's still not working though - I hope you won't mind continuing this thread.

The hosts don't seem to be able to sort it out. This is what they have:

name 192.168.1.5 fs2web

name 147.202.33.140 fs2

name 192.168.1.10 fs1web

name 147.202.32.85 fs1

static (inside,outside) fs1 fs1web dns netmask 255.255.255.255 0 0

static (inside,outside) fs2 fs2web dns netmask 255.255.255.255 0 0

static (inside,outside) 333.222.111.000 192.168.1.6 dns netmask 255.255.255.255 0 0

static (inside,outside) 333.222.111.000 192.168.1.11 dns netmask 255.255.255.255 0 0

static (inside,outside) 333.222.111.000 192.168.1.12 dns netmask 255.255.255.255 0 0

The software is 6.3(3) and they doubt that the upgrade will help.

Quote: "The only way you are going to be able to communicate between the machines and back to the machines is via the private interfaces. There is no way around this, as attempting to do so violate the core concepts of Private IPs vs Public IPs. The PIX in front of you is acting as the NAT gateway, basically there is no reason for it to ever communicate with itself in between the public and private IPs, as this information is stripped off at the NAT gateway (the PIX) for every packet that is incoming and outgoing. This is the nature of NAT, and not something we can change."

I agree with what they are saying - this goes against the purist view of NAT. But that doesn't mean it can't be done right?

If we really can't fix this I would like to ask if I could pay you some amount for the, probably, 5-10 mins work it would take for you to log in to my firewall and server to set this up. I'd really like you to gain something for the time you've spent. I can't afford $400/hr but $30-£50 for the job? I hope that doesn't cause offence... =|

Best wishes,

Daniel

[t-evens]

See my response to Scott in this thread or on experts-exchange for why it's most likely not working for you.

--Tim

[t-evens]

DNS doctoring (alias/dns) would work if the DNS response was forwarded through the firewall. So using alias or the dns keyword on a static might not do the trick because it depends where the DNS server was/is.

To answer the main question; the pix will not forward traffic back out the same interface it heard it from. This could open a hole in the firewall and thus compromise the security. So the two answers that exist are to use DNS doctoring providing the DNS server responses go through the firewall or use two interfaces on the firewall. Note that not even routers will NAT on the same interface.

--Tim

[scoclayton]

Sorry Daniel...I was out of the office for a few days.

Tim makes a good point and this was actually going to be my next post. Where is the DNS server in this design? I had been working under the assumption that the DNS server was on the outside interface and the DNS clients were on the inside interface. Can you clarify this for us?

Scott

[scottmac]

Just to clarify: the /etc/networks file would not be the place to enter a host. /etc/networks only provides a "name" to the network prefixes listed in the file.

You should have made an entry in the /etc/hosts file. That will map the IP address to the hostname before DNS is invoked.

FWIW

Scott

[cdonner64]

Have you considered putting an entry in your hosts file for s2 with its internal IP address, thus overriding DNS?

[danielwatts]

*SUMMARY OF THREAD*

Guys - thanks so much for picking up this thread.

Here is a summary:

The problem was due to a firewall stopping access from server side apps accessing other servers behind the firewall

by their Public IP addresses.

Several Solutions were proposed and tried, some of which were incorrect and some of which sound like they will work

but I have not tried.

Solution Index:

===============

1. Mapping in /etc/networks file

2. Mapping in /etc/hosts file

3. Dual DNS servers - one internal and one external

4. DNS translation at the PIX Firewall

Solution Detail:

================

1. Entering a mapping from IP to Hostname in the /etc/networks file

--This is a misuse of the networks file as pointed out. This is used to name entire networks and is not infact the

reverse of the /etc/hosts file. /etc/networks did not exist on my server anyway and its presence did not seem to do

anything at all.

2. Entering a mapping form IP to Hostname in the /etc/hosts file

--I did not think this was possible and actually only found out about this possibility after having fixed the

problem. I think this would work but I couldn't get my tests to do the desired.

3. Dual DNS servers - one for external queries and one for internal queries.

[Currently I have only an EXTERNAL dns provider]

--This in fact was considered but I felt that the solution was rather inelegant as the amount of added administration for all my 100+ domains would have caused a great deal of hassle. I was sure that one of the other proposed solutions would work so did not work in trying to implement this. I do know that "views" is the term used to describe such an implementation (ie internal view and external view).

4. DNS response IP remapping at the PIX Firewall.

-- By far the most elegant and simple solution:

**********PIX CONFIG*******************

name [__Internal_IP__] fs2web

name [__External_IP__] fs2

static (inside,outside) fs2 fs2web dns netmask 255.255.255.255 0 0

***************************************

Remember to "cl xlate"

The PIX software should be version 6.3(4) or above (works with 6.3(3) for me though!)

This solution initially did not prove fruitful. However - all of a sudden (more likely the firewall manager forgot to do the 'cl xlate' ) it started to work. Fantastic.

For those who would like to know how to check that this is working - simply do a "dig" dns query on a domain under the translated IP. The actual ip returned on output will in fact be the internal one.

***Thus all connections, via external DNS lookups, to hosts on public IPs but located within the private network, will ultimately recieve the correct local private ip address. ***

Aside:

======

This only leaves the situation whereby an entity tries to connect via IP itself. Any tips on how to handle this would be appreciated - I expect if we could get the /etc/hosts opposite mapping to work this could be the way. Eg

/etc/hosts:

192.168.0.1 62.123.123.123

[or would it be better to have:]

192.168.0.1 server1

server1 62.123.123.123

I hope that overview helps anyone new coming into this thread.

Many thanks to all again,

Daniel

[jpool]

This exchange has been very helpful to me in understanding the mystery of failed access by internal clients to internal servers.

While an internal client could use an internal address to access an internal server, this didn't seem optimal to me, for two reasons:

(1) Our PIX 501 is statically mapping address-port combinations to various internal servers, and it would be nice to allow internal clients use the work that has gone into this configuration.

(2) We want to use internal clients to test the ability of external clients to reach internal servers, so we want to use the same public address-port combinations as external clients would use.

I searched all the Cisco documentation, including posted articles, and found nothing addressing this configuration goal. It would be good to add a discussion of it to the configuration guide.

Anyway, extending the work done already in this discussion, I have tried two more solution strategies, because the DNS remapping doesn't help us when we query our own internal name server.

One that failed was to use the firewall's "alias" statement. It appears that the "alias" statement works only on traffic that passes through the firewall. So, if you try to use it to redefine a public destination address to a local destination address on the internal interface, thus redirecting traffic from local clients so it stays inside the firewall, it simply doesn't work, and the firewall continues to route such traffic to the public address on the outside interface. (It would be good to make it clear in the documentation that this is the case.)

One that succeeded was to add local addresses to our name server's zone file and add an address-ordering option to the name server's configuration. I added a second A record in the zone file, giving the local address, for each existing A record giving the public address. Then I added an option to the configuration file (/etc/named.conf) to make the order in which the two addresses appear in the response depend on the address from which the query comes. Queries from our local network get the local address first, and any other queries get the public address first. The (fairly convoluted) information on how to do this is in the named.conf man page. After some experimentation, I got a configuration that reliably works, which looks like this (where "nnn.nnn.nnn.nnn" is replaced with our public IP address):

options {

directory "/var/named";

// CUSTOM

sortlist {

{ localnets; };

{ any; { nnn.nnn.nnn.nnn; }; };

};

// /CUSTOM

};

While this solution "succeeds", it is still less functional than an in-out-in loopback functionality in the firewall would have been, since (1) it does nothing for queries that use the public IP address without requesting name resolution, and (2) it can't distribute queries that specify various ports of the server to various local servers. But I presume that one can get all that functionality by adding a router inside the firewall.

If anybody has additional solutions or refinements, I'd be happy to see them.

[danielwatts]

Hi there - glad you found the discussion helpful!

You seem to be after what I was originaly after - essentially "Same Side NAT".

I still think this should be possible but it seems a lot of people just look at me funny when I suggest it as it is completely against the whole NAT principle.

What I can offer is a slightly nicer DNS solution. Use views. A random result from google is: http://www.acmebw.com/askmrdns/archive.php?category=89&question=621

I'm not sure exactly what you need with your port rerouting though I expect an internal router will handle that for you as you say.

Dan