Accessing DMZ web server from internal network

[bth_dad]

I have a web server that sits in my DMZ that we can access today using it's private IP address. When I do an alias OR outside nat to allow my internal users to access a web site on that server by public IP, we loose all private IP access to the server. Is there a way to NAT from the inside interface to the DMZ interface so that we can access the server by public IP without disrupting our private IP access?

Here are the pertinent parts of my config...

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 DMZ security50

access-list acl_in permit icmp any any

access-list acl_out permit icmp any any

access-list outside permit tcp any host 216.176.95.10 eq www

access-list DMZ permit ip any 10.1.0.0 255.255.0.0

ip address outside 216.176.95.xxx 255.255.255.128

ip address inside 10.1.240.xxx 255.255.255.0

ip address DMZ 10.1.241.xxx 255.255.255.192

global (outside) 1 216.176.95.xxx

global (DMZ) 1 10.1.241.xxx

nat (inside) 1 10.1.0.0 255.255.0.0 0 0

nat (DMZ) 1 10.1.241.xxx 255.255.255.192 0 0

static (outside,DMZ) 216.176.95.10 10.1.241.69 netmask 255.255.255.255

access-group outside in interface outside

access-group DMZ in interface DMZ

route outside 0.0.0.0 0.0.0.0 216.176.95.126 1

route inside 10.1.0.0 255.255.0.0 10.1.240.254 1

Thanks for any help

Todd

[steve.barlow]

Two options:

1) Follow the link concerning the alias command: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094aee.shtml

2) Change your internal DNS to point to the private IP of the web server on your DMZ.

Hope it helps.

Steve

[bth_dad]

Same problem. I can now reach the web site with my browser, but we cannot telnet or ftp to the box for maintenance using the private IP address. I remove the alias command and I can telnet to it, but then I can't reach the web site. I would think there has to be a way to do both?

Thanks for your reply though.

Todd

[gfullage]

What format are you using for the alias command? If you're doing DNS Doctoring, you'll have something like:

> alias (inside) 10.1.241.69 216.176.95.10 255.255.255.255

If the WWW server is on the DMZ though you should be using Destination NAT, not DNS Doctoring. Reverse the alias command to be:

> alias (inside) 216.176.95.10 10.1.241.69 255.255.255.255

This way the DNS query will be left at the external address, but when your inside clients try to connect to that, the PIX will redirect the packets to the internal address. Your external users should work as normal with the static command.

[bth_dad]

Again, this allows me to get to the box using my public address, but I can't telnet or FTP to it using the private IP (10.1.241.69). I can ping it though, so I am seeing a TCP problem....?

[gfullage]

So with the 2nd format of the command (DEstination NAT) you can ping the internal IP address but can't telnet to it? The alias command in this format shouldn't be doing anything to the packet since the destination is the 10.1.241.69 address and the alias command doesn't match on that, so the packet should just go straight through.

What does the syslog on the PIX show when you try and telnet? Can you telnet to this server from a PC on the DMZ segment?

[shannong]

I'm assuming the DNS for the URL/host is hosted outside and resolving to a public IP for your users.

If you're running 6.2.x or higher, you can use bi-directional NAT to resolve this. This is better than using the "alias" command because you will maintain full functionality of the PDM as the PDM does not support the alias command. Note that you cannot have access to both private and public IP at the same time regardless of the Pix's configuration. Instead we can make all access to that server occur with the external DNS resolution that is already working for us.

I recommend you do this:

1.Remove the "alias" command if it's still there.

2.Modify you current static to include DNS doctoring:

static (DMZ,outside) 216.176.95.10 10.1.241.69 dns net 255.255.255.255

3. Add a new static nat to let your internal users access the public IP from inside:

static (DMZ,inside) 216.176.95.10 10.1.241.69 net 255.255.255.255

4. clear xlate

All access to that server from inside users can be had now using the public IP that external DNS is delivering. All drive mappings, URL requests, FTP, etc. will use the public IP and the Pix will NAT the traffic back to the private IP as it heads out to the DMZ. So let your external DNS handle everything for you. This will sometimes be a problem if you're in a Win2k domain and that server is on the domain information with its private IP. However, this shouldn't be an issue because your public web server SHOULD NOT be on your internal domain. If it is, you have security problems of all sorts of which this is the smallest. Also, I assume this not to be the case because otherwise your interal Win2k DNS would already be resolving the host to its private and we wouldn't have any problems to begin with.

Hosts on the local DMZ with the server will have DNS replies docotored with the Private IP due to the use of the "dns" option of the static command.

I've used this configuration several times now without any problems. Again, make sure you upgrade your code to 6.2(x) or better for these features!