Accessing Public NATed IP from Inside....

dmepix · ‎10-19-2004

Is it possible to access a NATed ip on the outside interface from the inside. I have a webserver on the DMZ interface of my firewall and was wondering if it is possible to go through the same path as everyone hitting it from the outside from the inside?

THanks

Tripp

Patrick Iseli · ‎10-19-2004

No, this is not possible. To access a WebServer from the inside to a DMZ you can use a "NAT 0" or a static that disables NAT from the inside too the DMZ, see bellow.

Lets say 10.x.x.x is inside and 20.x.x.x is the DMZ

nat (inside) 0 access-list no-nat

access-list no-nat permit ip 10.0.0.0 255.255.255.0 20.0.0.0 255.255.255.0

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.255.255.0 0 0

check out this link:

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008015efa9.shtml

sincerely

Patrick

dmepix · ‎10-20-2004

Ok. Is there a work around for this or is the software and hardware unable to do this at all?

Thank you for your help Patrick.

Tripp

Patrick Iseli · ‎10-20-2004

This is Firewall (PIX) OS Related, but I think this might be fixed in PIX FOS 7.0. FOS 7.0 will for example allow that Multiple VPN can directly talk to each other , called "spoke VPN".

The PIX does not allow to leave the outside interface and then come back on the same interface to go into the DMZ. To do so diable nat from the inside to the DMZ.

sincerely

Patrick

dmepix · ‎10-20-2004

Where could I get the PIX FOS 7.0?

scoclayton · ‎10-20-2004

The restrictions in question on this post will not be lifted in the 7.0 release of PIX code. 7.0 will allow for VPN packets only to be "u-turned" on an interface. However, this has little to do with the issue at hand.

Scott

dmepix · ‎10-20-2004

Patrick,

Once again thanks you for the response. If i disable NAT on the inside of the firewall will that cause traffic to stop between the dmz and inside? Or will that stop traffic from the inside to outside? WHat ramification would take place if I was to disable NAT on the inside interface.

Thanks again

Tripp

Patrick Iseli · ‎10-20-2004

Disable NAT between inside and dmz means that all packets will use their local private IPs.

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.255.255.0 0 0

So all traffic from 10.x.x.x to the DMZ will not follow the "nat (inside) n" and "global (xx) n" statement.

Do not touch the statics that NAT the public to DMZ translations.

You do not need to translate addresses from the inside to the DMZ.

sincerely

Patrick

scoclayton · ‎10-20-2004

Patrick and Tripp,

I don't believe the info provided *completely* solves Tripp's problem. Please correct me if I am wrong on this...here is what I think is happening.

Internal clients do a DNS lookup for a webserver that sits on the DMZ. The DNS server is located outside the PIX at the ISP (as an example). Since the main purpose of this DNS server is serve the webserver address to users on the Internet, the DNS server returns the global address for the webserver. The internal clients inside the PIX also get this global address when they resolve the name via this same DNS server but are unable to hit the webserver via this address due to the fact that the PIX cannot route the packets destined for the global address back to the webserver on the DMZ. The internal clients can probably hit the webserver on the DMZ if they type in the local address of the server in their web browser (i.e. they don't use the name). How close am I?

If this is the case, you need to do what Patrick is referring to which allows the webserver to get back to the internal clients. However, the issue of getting the packets from the internal clients to the webserver on the DMZ via the global address still remains. But, we can fix this too.

We added a new feature in PIX 6.2 code (I think) called destination NAT. Which means, we can NAT the destination address (rather than the source address as we normally do) as long as the packets are passing through (from one interface to another interface) the PIX. In your case, you would want to add something like this:

static (dmz,inside) 1.2.3.4 10.1.1.1

where 1.2.3.4 is the global address that the internal clients get when they resolve the DNS name and 10.1.1.1 is the actual address assigned to the webservers NIC on the DMZ.

Make any sense?

Scott

dmepix · ‎10-20-2004

Scott and Patrick,

I appreciate the attempts on getting this issue solved. The issue is that we have some dev/sales men here that want to be able to access the public facing ip that is NATed through the firewall from inside interface of the firewall. Now if I do the static mapping you are speaking of Scott will that allow me to access the public facing ip?

THanks for your assistance in this matter gentleman.

Tripp

scoclayton · ‎10-20-2004

Yes. You will not have to change anything on the client side for this to work. All you are simply doing is taking packets on the inside interface destined for 1.2.3.4 and translating them to 10.1.1.1 on the DMZ interface. When the DMZ server responds, the PIX does the reverse translation so the client thinks he is actually getting a response back from 1.2.3.4. (the addresses are just an example).

Make sense?

Scott

Patrick Iseli · ‎10-20-2004

Scott,

do you talk about the "sysopt route dnat"? This work for 6.2.x but not for 6.3.x.

The DNS doctoring could be done to solve this!!

Understanding the alias Command for the Cisco Secure PIX Firewall

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aee.shtml

Destination NAT is deprecated in 6.3.

http://www.cisco.com/en/US/products/sw/secursw/ps2120/products_command_reference_chapter09186a00801727aa.html

The following commands are no longer used to configure the firewall: sysopt route dnat ....

Thanks a lot for your feedback Scott

sincerely

Patrick

scoclayton · ‎10-20-2004

No, I am not referring to "sysopt route dnat". I am referring to using a static to translate destination addresses as opposed to the usual method a static works (translating sources). Yes, "sysopt route dnat" has been deprecated from the 6.3 release. This command has had very little use in a long, long time.

And finally, yes, DNS doctoring could also solve this issue but I would advise against using the alias command as the alias command will be deprecated in the next release of PIX code. You can accomplish the DNS doctoring by building a static with the 'dns' keyword specified.

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

I promise you, I do actually know what I am talking about sometimes ;)

Scott

Patrick Iseli · ‎10-20-2004

OK Scott,

I got it ;-).

Took me some time....

I know that you actually know what you are talking about

dmepix · ‎10-21-2004

Well...Gentleman...Again Thank you for your input. I am goign to test this out tomorrow in the am to see if I can make some magic happen. I understand the logic behind this now. I will let you gentleman know what the outcome is.

Thank you for your assistance.

Tripp

I love these forums! Great Techs and most of all GREAT people. Thanks again. I will keep you posted.