ATTENTION: We are currently working an issue with posting. Thank you for your patience while we work on a resolution.
cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
382
Views
0
Helpful
1
Replies

Problem with Static NAT and Port Numbers (Static PAT) 8.2

paultribe
Level 1
Level 1

I have an issue which I am struggling to resolve. I have been approaced  by a potebtial customer who have an ASA which has an Inside interface, Outside interfac and DMZ interface.

- They have a live web server on the DMZ for example 192.168.10.50 accessed via port 80 and 22 only.

- The server is accessed from internal and external.

- From the inside for example network 10.10.10.0/24, there is a blanket NAT exemption rule.

- There is an access list on the inside interface that permits port 80 and 22 from 10.10.10.0/24 to 19.168.10.50.

- From the outside they have a static one to one NAT that translates for example 7.7.7.7 to 19.168.10.50.

Everything works fine.....

- They introduce a test web server to the DMZ for example 192.168.10.51 to be accessed via port 81 and 23 only. But only have a single public IP address to use which is the 7.7.7.7 address.

I suggest using static NAT with port numbers on the outside interface so remove the static one to one NAT and replace with four entries:

- 7.7.7.7 to 192.168.10.50 on port 80

- 7.7.7.7 to 192.168.10.50 on port 22

- 7.7.7.7 to 192.168.10.51 on port 81

- 7.7.7.7 to 192.168.10.51 on port 23

Basic tests prove the translation rules work by accessing both servers direct on any ports from any interface however, problems start to occur whilst trying to access the live web server from either the inside or outside when accessing them how typical users do which is detailed below (And worked before):

To connect to the web server on the DMZ users access Internet Terms & Conditions page on a host on the inside network for example 10.10.10.33 using a DNS name, when they access the page they click ACCEPT and are then forwarded to the web server. Thereis now a huge delay in delivering the page. Examination of the HTML code proves that the ACCEPT button does point to a URL that is associated with the correct IP address.

The firewall logs show nothing other than the TCP connection being built a message about the URL being accessed and then a long delay before the page finally appears.

If the translation rules are reversed the page responds immediately.

Does anyone have any ideas what the problem maybe, is it DNS related, what causes the ASA to give a message about URL being accessed, there are no filters configured and no websense configured ?

1 Reply 1

mirober2
Cisco Employee
Cisco Employee

Hi Paul,

First, can you share a sanitized copy of your configuration? What do you mean when you say "If the translation rules are reversed the page responds immediately"?

Packet captures taken on the outside and DMZ interfaces when a user faces the problem would be helpful in identifying the problem. Here is a guide to setting up and downloading captures from the ASA:

https://supportforums.cisco.com/docs/DOC-1222

Also, to answer your question about what causes the message about a URL being accessed, this is triggered by the HTTP inspection engine on the ASA. You can try removing the 'inspect http' command from your configuration and see if this makes a difference.

-Mike

Review Cisco Networking for a $25 gift card